CD ROM Paradise Collection 4

home *** CD-ROM | disk | FTP | other *** search

/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / bbs / jdrbbs10.zip / DOCS_ETC.ZIP / DOCS.DOC < prev next >

Wrap

Text File | 1994-12-22 | 432KB | 7,891 lines

Juggernaut .10 Juggernaut is a complete Computer Bulletin Board System (BBS). It has the power to do everything you expect from your BBS software, and the flexibility to do its job in whatever manner you desire. This software contains completely original programming, with many new, and unique, ideas and methods. Including unlimited expansion and growth potential. Incorporating much in itself that other programs rely on 3rd-party software to accomplish. The interface is FAST! Logging on and doing things are all optimized in the interface. Hot-key menu action on all things. The software is balanced. Users and sysops have many options, and much power, at their control. Raw POWER! Let the adventure begin... CONTENTS WHY SETUP A BBS? ...........................................1 ORGANIZATION ...............................................2 LIMITS .....................................................3 NOTICE .....................................................4 REGISTRATION ...............................................5 Registered package .......................................6 DISCLAIMER .................................................8 SUPPORT ....................................................9 STARTING UP ...............................................10 TRY OUT ...................................................11 RESTARTING ................................................13 Config ..................................................14 INPUTING ..................................................16 Censoring ...............................................17 Active spelling checker .................................18 Search string chopper ...................................18 Internal Menus ..........................................19 CONSOLE KEYS ..............................................20 From <alt>d .............................................20 When a user is on-line ..................................20 Definable ...............................................21 Misc. ...................................................22 LOGGING ...................................................23 Callers log .............................................23 Errors log ..............................................24 Session log .............................................24 Chat log ................................................24 EH? .......................................................24 LOGIN .....................................................25 User Names ..............................................25 Login (cont.) ...........................................26 READING MESSAGES ..........................................27 Header ..................................................27 Body ....................................................27 Footer ..................................................28 Commands ................................................28 ? .....................................................29 [Enter] ...............................................29 <right>/<tab> .........................................29 <down>/+ ..............................................29 <left>/<backspace> ....................................29 <up>/- ................................................29 Again .................................................29 Continue message ......................................29 Delete ................................................29 Edit ..................................................29 Forward ...............................................30 Get files .............................................30 Give files ............................................31 Next ..................................................31 Previous ..............................................31 Quit ..................................................31 Reply .................................................31 View a file attach ....................................31 eXit to menu ..........................................32 Sysop Commands ..........................................32 Misc. ...................................................33 ENTERING MESSAGES .........................................34 Heading Line ............................................34 In ......................................................34 To ......................................................34 Subject .................................................35 At ......................................................35 Line numbers ............................................36 Quote original ..........................................36 Upload message ..........................................36 Carbon Copies ...........................................37 File Attaches ...........................................37 Reception Report ........................................37 Encrypt .................................................38 Do A Freq ...............................................38 Net FAs .................................................38 Body ....................................................38 Command Line ............................................39 % .....................................................40 Abort .................................................40 Continue entering .....................................40 Delete lines ..........................................40 Edit ..................................................40 Finish later ..........................................40 Grammar check .........................................41 Insert lines ..........................................41 List ..................................................41 Preview ...............................................41 Save ..................................................42 MESSAGE FILES .............................................43 RAMBLINGS .................................................45 FILE AREA CONTENTS LISTING ................................46 Paged System ............................................46 The display ...........................................46 Command line ..........................................47 User commands .........................................48 Sysop/File-Op commands ................................50 Auto-delete curses ....................................52 Point & Shoot File Selection and Information System .....53 DOWNLOADING ...............................................55 UPLOADING .................................................58 Searching ...............................................59 File Descriptions .......................................59 REMOVING FILES ............................................61 MISC. .....................................................63 I AM LOST!?! ..............................................64 CUSTOMIZING 101 ...........................................65 TOGGLES ...................................................66 SETTINGS ..................................................67 PATHNAMES .................................................68 MENU COMMANDS .............................................69 ANSI'S ....................................................70 CONVERSION ................................................71 MODEM SETUP ...............................................72 Example .................................................73 CONNECTs DB .............................................74 Throughput ..............................................75 TERMINAL PROGRAM ..........................................76 Dialer ..................................................76 Command Line ............................................76 Misc. ...................................................77 CUSTOMIZING 201 ...........................................80 SECURITY LEVELS ...........................................83 Ghosting ................................................83 SYSOPS ....................................................85 Co-Sysop's ..............................................85 File-Op's ...............................................85 FILE AREAS ................................................87 Defining ................................................87 Menus ...................................................93 Diagrammed File Examples ................................95 Files In Area ...........................................97 CD-ROM's ................................................98 Special Cases ...........................................98 Ghosting files .........................................100 MESSAGE AREAS ............................................101 Defining ...............................................101 Menus ..................................................104 Toggling ...............................................104 PSEUDO-AI ................................................105 MINUTES ..................................................106 GROUPS ...................................................107 VOTING ...................................................108 DOORS ....................................................110 Defining ...............................................110 Menus ..................................................114 Time Maintenance .......................................114 Misc. ..................................................115 PROTOCOLS ................................................116 Defining ...............................................116 MENU SYSTEM ..............................................121 Definition .............................................121 McEditor ...............................................122 Menus ..................................................124 Command Objects ........................................126 Commands ...............................................128 Misc. ..................................................128 WAITING FOR CALLER SCREEN ................................130 THE "WHO'S ON" STATUS LINE ...............................133 ACCOUNT VALUE ............................................134 EVENTS ...................................................135 Defining ...............................................135 OH OH! ...................................................138 STYLES\LANGUAGES .........................................139 Directories ............................................140 Styles .................................................142 Languages ..............................................143 Your own style .........................................143 Menu Commands ..........................................143 TEXT FILE MANAGEMENT SYSTEM ..............................146 DIRECTRY'S ...............................................147 USER VOTING ..............................................149 Peer Review ............................................149 Sysop InfoForms ........................................150 DATABASER ................................................151 DB_BLKS.TXT DataBaser Structure ........................151 Calling Via Menus ......................................155 Modifying ..............................................155 More ...................................................155 LIFE & DEATH DELETE ......................................159 MULTI-NODE OPERATIONS ....................................160 INTERNAL NETS ............................................162 Null Link ..............................................162 LANs ...................................................162 Null LAN ...............................................163 FILE CORRUPTION ..........................................164 SPECIAL THANKS ...........................................165 NEXT .....................................................166 -1- WHY SETUP A For the corporation, a BBS is an inexpensive method of BBS? distributing software to its customers. Providing a way for customers who do not have 3.5" disk drives to easily get the software, rather than the company (and customer) going through the time and expense of either sending a 5.25" disk, or including both types with each software product. The BBS optional provides faster turn-around response time as well. A BBS also provides the corporation with a method of easily distributing updated versions of each software product. When a customer finds a bug in a piece of software, they blame two companies: the original author, and the one that sold it to them. Both companies have a good chance of never hearing again from that customer. A BBS allows your older customers to get the same software updates you include for the newer customers. Finally, it provides a way for the corporation to distribute "undistributable" documents to its customers. Such things as: complete price lists, technical specifications about hardware products, "commonly asked questions" of your technical support lines, documents on the historical and tested performance of the various hardware products. The same documents that companies sent to you to convince you to carry their line can be used on a BBS to help generate sales. For the individual, a BBS provides a temple of power for yourself. Software comes to you. You provide a service for other people. You are able to get your thoughts, ideas, beliefs, and knowledge out into the world where all can see. You can even make a BBS a business and get money running one (if you are willing to make the initial investment to become a huge multi-node BBS, or a smaller many multi-lined chat BBS). A BBS provides you and your callers with access to many mail echo's from around the world, and is a must if you want to start your own mail echo to send around the world. For the individual, who does not want to run a public access system, a BBS program is superior to a normal communications program because of its net mail capabilities. It also provides a way to quickly exchange information between your friends any time of the day as a private BBS. Why this BBS program? Because it provides more flexibility of design in its presentations to callers than any other BBS program. What you envision, this software can make real; no sacrifices, no compromises, only your vision. -2- ORGANIZATION Most of the user-accessible functions of a BBS need to be relatively easy to understand when they are used on-line. These docs were organized to provide additional information for the sysop. In many cases, the details are of the type that only a programmer would think to note--feel free to skim past stuff you do not understand, and to skim even faster past stuff you already do understand. Typically, the first questions I am asked is "can the sysop design their own menus," and "can the sysop move commands from one menu to another"--Yes, to both. Q&A.DOC contains some other questions I've been asked, and might be worth looking over. About half the docs are on-line in the form of on-line docs for such things as Toggles, Settings, and Menu Commands. So if you do not find the answer to a question in these docs, or the HELP directory, try the on-line docs (most stored in MENUCMDS.TXT if you want to print them out). This software can be tricky. It does almost everything in more than one way--leaving it up to the sysop to select which way to do what they want. This capability adds some complexity, but once you realize that it is "organized complexity" you will be fine. -3- LIMITS Mostly your RAM and drive space are your only limiting factors. 1000 file areas. 100 voting questions. 1000 message areas. 32,000 active messages per message area. Message numbers can go to 2,100,000,000. 25 of your own defined data bases. 32,000 door programs. 99 undergoing-peer-review users. 32,000 entries in the databases. 32,000+ active users. 32,000+ active files on-line. The above limits can be increased if needed, just ask. -4- NOTICE This is not a pre-release, alpha, or beta version. I will be numbering my releases .01 to .99. "1" being a perfect program, so anything short of perfection merely approaches 1. "r.09" means "release .09", or "release #9". A release is when I take the time to actually update everything and distribute it to release sites. No small undertaking. In between releases, I release JMODxxyy files which contain any bug fixes, additional docs, and other interesting stuff. XX will be the release number, and YY the release number for the JMOD file. Example: JMOD0904 would be the 4th release of the JMOD file for release .09 of JDR_BBS. Any releases before the latest one are contained within, so there is no need to ever get an old JMOD. JMOD files usually start appearing about a month after release, and are updated about every month or two. I make a great effort each release to test everything for bugs, but there is no such thing as bug-free software. New versions will be released every 3 to 12 months. It is an evolving product. In many cases, the ideas you relay to me will appear in the very next release. When I mention "sysop" that's you--and anyone of your same Security Level (usually). When I mention "caller" or "user" those are non-sysops. Example, when I say "users don't see this" I mean that the caller will not see it, but at the console you will see it. If you find anything not to your liking, please tell me. New ideas need not change the old method, this program is designed to do many same things differently. It is ready to run now, just INSTALL it and run it--even if you are running a BBS on COM1, do not worry, it will be in local mode. -5- REGISTRATION Required within 30 days of use. See ORDER.FRM for pricing information. The version you are using is fully functional. Registering is required for continued use, and provides many additional capabilities--including the source code (Basic/Assembly). Many of these additional capabilities are listed on the sysop menus in violet. Besides the additional sysop commands, the post-upload- processing stuff is also registered. That includes importing FILE_ID.DIZ's, inserting archive comments, virus checkers, etc. However, at the last minute I decided to allow importing of FILE_ID.DIZ files (either after an upload or with the Post Upload Processing sysop menu command) for ZIPs only--to provide you a better opportunity to examine the file system. Thus, the unregistered cannot do the sysop commands in violet, does very limited file post-upload-processing, and cannot do compression-related stuff (compressing messages, etc.) What was selected to be registered were not things that cripple the operations of the BBS, or penalize the users, but rather enhancements that a sysop would like. Since, ultimately, it is the sysop who registers this. If you are a company, you must do a corporate registration. If you are an individual, you may choose personal or corporate registration. Registrations are site licenses. Each computer running this software must be individually registered. A single computer multitasking three phone lines is considered one computer. Workstations on a LAN or WAN are individual computers, but usually only the server runs the software. Cash, check, or money orders only. For extra safety, you can send it via certified mail. A wire transfer may also be acceptable, but require an additional charge. Credit cards may be acceptable in the future, so if you want to use one, ask first--but it is likely to add another 25% to the registration fee (that was the fee of the last credit-cards- for-BBSs provider I looked at). Registrations are lifetime. Technical support is also lifetime. All future versions will be considered registered for you, with one exception: a possible Windows-only version I may develop in parallel to this line. This software here -6- will be getting itself split into a DOS and Windows version over the next year or two. The Windows-only BBS software I'm thinking of doing would be a more simpler commercial version. Registrations are non-transferable. You may not sell it, trade it, or give it to someone else. One of the reasons for the extra cost of the Corporate registration is that this registration tends to transfer from employee to employee as different employee's take on the task of maintaining the BBS. This is acceptable for Corporate registrations as long as it is inside the company. Personal registrations may not do this. Example, a personal registrar may not give the registration to his friend--personal registrations are individual and non-transferable always. Registration does not grant you ownership of the source code. You may not recompile and resell the program in any form, or parts thereof, without the authors permission. The source code is solely for your own in-house modifications. If you wish to license part(s) of the source code, contact the author. Registered Registration will get the registered version of Juggernaut. package It is essentially the same program, but with a lot of extras made accessible. The registered package has, over these years, gotten reduced to a single letter confirming that you are registered, and card containing your key codes. Everything else is given to you via File Attaches on Immortality. In the future, I will be expanding this capability to the distribution sites and Internet, and making it much more automatic. I have found that sending disks through the mail was just getting them partially corrupt half the time. A mailman may be willing to go through extreme conditions, but data on disks hate it. Also, the software has simply changed too fast to make printed manuals practical. Although I am hopeful this will change in the future. After registering, you will be given a package of files which include a registered version of JDRBBS.EXE, the docs for the registered capabilities, and information about how to hook into the support network. Other things include some free upload bytes on Immortality, access to the encrypted Registered Sysops echo, your own node address on the support network, and you can optionally have your BBS appear in the list of active registered sites. -7- You will be able to get future releases free of charge off my BBS. A distribution network is also being set up. So register today! There are many good things yet to be added to this software, and your support will help make this possible. -8- DISCLAIMER I make no warranties of any kind, either expressed or implied, as to the fitness of use, quality, or performance of this software. In no manner shall I be held liable or responsible for any losses or damages arising from the use of this software. See also: NOT_DOCS.DOC -9- SUPPORT I can be reached as follows: Physical mail: John Rohner POB 340304 Milw., WI 53215 If just a question, include a SASE. Electronic mail: John Rohner (sysop) Immortality (414) 643-1576 Internet: rohner@csd.uwm.edu Not stable, if no reply in a week then call the BBS. Usenet groups: alt.bbs alt.bbs.allsysop comp.bbs.misc Also not stable. Net mail: Immortality (414) 643-1576 Must be direct call. The BBS accepts mail 24 hours. Voice: Rarely given out. FidoNet: not yet... I would prefer that you use a public area to post any messages concerning this software. Usually the "Juggernaut Support" area on my BBS. That way other sysops get to see the message. Many private messages to me concerning questions about the software will be forwarded to the public areas. Ideally, you should try to post the message in the following order: Juggernaut Support on my BBS (echo'd to other sysops). BBS related echos on the Internet. Feedback to me on my BBS. E-mail to me on the Internet. You can also contact any BBS which has registered the software, usually they are pretty smart about how it works. -10- STARTING UP To make full use of this software, you will need the following (listed in order of importance): ∙ A '286, 640k, or better computer. ∙ One or more hard disks. ∙ A modem. ∙ The latest version of PKZip/PKUnZip. ∙ A fossil communications driver (such as X00, BNU, etc.) (included in the sample \UPLOADS area) ∙ A protocol driver, such as DSZ or GSZ. ∙ Your favorite text editor. ∙ An ANSI editor, such as The Draw. The following are optional, but every good BBS needs them: ∙ The latest version of ARJ. ∙ The latest version of LHA. ∙ You will probably also want the latest version of PKLite or similar (for reducing .EXE's). ∙ The latest version of BiModem. ∙ A disk defragmenting utility. ∙ A VGA monitor (for GIP graphics) Don't be put off by that VGA monitor bit--it is in no way required to use this software. But the software is getting more graphical with each version, so it is nice to have. If you cannot find any of the software on your local BBS's, then give mine a call and you can download it from there. The software works fine with disk compressing programs (Stacker, DoubleSpace, SuperStor) and under a variety of operating environments (DOS, DesqView, Windows). It does not do any "oddball" things, nor does it attempt to take advantage of the OS you put it in--it is environment friendly. -11- TRY OUT Just run JDRBBS.EXE. It is configured with comm port = 0 (local/console mode) so you do not have to worry about hooking up a modem/etc. right now. It will use the current drive as its basis drive, and will initialize the #NEWUSER new user record (the first user record). #NEWUSER is the name given to the very first record in the Users file. All new users are given a copy of this record as their starting record. You may edit these values like any other user entry, just specify "#NEWUSER" for the user's name. For most things, the #NEWUSER entry/name is invisible. Technical note: The software keys on the existence of PATHS.DAT to determine when you first run it. It then creates PATHS.DAT, BBS001.BAT, DOOR001.BAT, and BACKUP.BAT. It also sets the comm port to zero, re-initialize's #NEWUSER to the default settings, and sets the waiting-for-caller drives-to-show to the current drive. Finally, it goes through all your small SYSTEM\*.DAT files, and text-block files, and changes "C:\" to whatever your current drive is, and any "system operator's" to your sysop name. That is all. Which means if you accidentally delete PATHS.DAT, you do not have to fear for the rest of your files. Deleting PATHS.DAT is a good first step when moving the BBS to a different drive letter. Because it is set for local-only operation (Comm port = 0), it will automatically display the logo and start the login process. Follow what it says. It is just like logging onto a normal BBS. One thing you will notice immediately is that instead of "password:" I use "verification:". You can change it if you like. "Password" was just too archaic for me. After all, "my pass word", "]I[ %5^&890", and "643-1576" are all valid, and hardly a word. Now that you are in, play around with it, get to know it. I have pre-created the following for you: 1 File Area: UPLOADS a few Message Areas 2 doors: ED.EXE (PC-Write) CSHOW.EXE (CompuShow) 7 voting questions 1 ramble 8 Security Levels Some sample MESSAGE.### files. 3 Directry files: Unprotects Music Quotes Other Ansi's A whole bunch of sample menu sets (Styles\Languages). -12- This is so you can get some general feel for the software and its capabilities. After looking around, hit <alt>u. This is the user maintenance--change your Security Level to 100. Hitting "!" at the main menu brings up the sysop menu. You should make sure the .EXE and/or paths are correct in the following instances: File Areas Maintenance Protocols Executable Lines Door Maintenance Do not worry about the communication parameters for now. You may quit the software by hitting <alt>x. See also: CUSTOMIZING 101, CUSTOMIZING 201, MODEM SETUP, CONFIG, SETTINGS, PATHNAMES -13- RESTARTING After the first time, always use "BBS001" (as in BBS001.BAT) to run the BBS. Or rather BBS### where "###" is the node number you wish to run. If using only one node, it is easier to just copy BBS001.BAT to BBS.BAT and just type "BBS" to run the program. You may use JDRBBS /? (or BBS001 /?) to bring up a list of what command-line commands are available. They are: /? to get a help list. /NODE=x to start up node x. Where "x" is a number from 1 to 999. Optional for Node 1, but required for any nodes larger than 1. /PORT=x to re-set the current comm port to x. Where "x" is a number from 0 to 4 (or higher if your fossil supports it). /BAUD=x to reset the baud rate the computer talks to the modem at. "x" is one of: 1200, 2400, 9600, 19200, or 38400. /INIT=x to define what your modem's initialization string should be. Example: ATZ, ATE1X4, AT&F&C1&D2H0, etc. /1STCMD=xxxx to re-set the first command to xxxx. "xxxx" must be a four letter command. You may run a single command by doing: JDRBBS /1STCMD=xxxx BBS001 /1STCMD=STRT the first part runs JDRBBS and executes the command "xxxx", the second part re-sets it properly. "xxxx" should not be a command that requires the user's name unless you put a "LogN" as the first command in "xxxx"'s command list. Probably "/BAUD=0" then "/BAUD=n" needs to be done for some commands--otherwise it exits because it does not find a carrier on the currently defined port. /NODIRECT to turn direct screen writing OFF. /RESCAN do a complete re-scanning of your file areas against what you have on disk, updating your on-line file lists appropriately. -14- /RESCANALL same as /RESCAN, but will do all areas whereas /RESCAN will only do those areas with File Area Attribute 9 OFF. /USEVGA some sysop commands have VGA versions and ANSI versions. When you use this, it will select to use the VGA versions. It will also change to 50 line mode when a caller is using a > 25 video height. **If you have a VGA monitor, and do not need to run in text mode for something like a multi-tasker, I strongly urge you to use this parameter in your BBS001.BAT file. It's great! Also lets you see what users see if they have > 25 screen heights (which otherwise mess up the local console). /USE50 this will lock the console in 50 line display mode. It also use the VGA alternative displays. /NOEVENTS this will not execute any events that were to occur since the last time the BBS was active. Useful if you had it off-line for a while, and want to get on right away rather than waiting for it to first finish some scheduled event. It does not affect future events, just those missed while inactive. Each command must have no spaces within it. So "/node = 1" will not work. "/", "-", "\", or nothing at all may be used as leading characters. There are Settings for the modem stuff, but these command line versions are a bit easier, and provide a way to recover if you enter bad modem information that doesn't set up the modem properly. Technical note: only those /cmds inside BBS###.BAT will be re-executed if you do a full-exit door. Config Below is what my CONFIG.SYS and AUTOEXEC.BAT look like: CONFIG.SYS: buffers = 25 files = 20 device = x00.sys T=2048 eliminate -15- AUTOEXEC.BAT: path \dos;\bbs\bin; break off verify off cd \bbs Turning "break off" and "verify off" is an old BBS'ers trick, allowing faster disk accesses. If you just want to look around--not run the BBS, just ignore the CONFIG/AUTOEXEC stuff. -16- INPUTING In most cases inputing of file names and user names utilize "auto-completion"--you start it, the software finishes it. With every keystroke, when entering a file or user name, the software searches through all entries and looks to see if there is only one possible match. The software will then send the remaining keystrokes out--saving the user the need to type it. If what the user types has no match, then it is ignored. I have found that, for user names at least, most sysops seem to turn this off right away. But think twice before turning off the file name auto-completion, it really is handy--helps by not needing to memorize filenames. When entering user names, you may type a "*" or a "?" anytime after the first character. When this is detected, a list of all the users matching those letters will appear. Example: typing JOHN* would show all users with names with the first 4 letters "JOHN". This is mostly useful for when entering messages TO: a person in a message area that allows any TO: name (thus no auto-name-detect, such as net mail areas). Some answer fields, that have a size limit, automatically do a [Enter] when you reach the end of the field. Security Levels, in some places, can be entered by entering a range--either a single value, or two values separated by the word "to" (eg. "5 to 20"). In most situations, a [Space] (or [Tab]) will pause the text, and an [Enter] will cancel or exit an option. For times, a 24 hour clock is assumed. This means that an hour of "0" is midnight, "12 is noon. A day starts at "00:00:00" (midnight) and goes through to "23:59:59" (11:59 pm). Because of the way seconds are stored, they may be off by one second from what you entered. A 00:00:00 to 00:00:00 range means available 24 hours (indeed, any two matching times mean to use the full 24 hours). For 24 hour restriction, use 00:00:00 to 23:59:59. You must enter the full 8 characters (HH:MM:SS) or you will get random results. Phone numbers have become tricky these days. In order to make everyone happen, no processing of what was entered is done. Call-back verification is the only place this really matters. Whenever you enter full pathnames, you should always include the leading drive letter. Example: "c:\uploads\test.zip" not "\uploads\test.zip". -17- See the file HELP\KEYS.HLP on information about how to colorize text and produce international characters (users and sysops can do this--even in their names). When a user receives a beep, such as during active grammar check, or after file transfers, the console will not get the beep (to preserve sysop sanity). If you are the sysop, and/or at the console, then most of the "inactivity time-out" timers will be ignored. This is not true when doing some commands from the Waiting-For-Caller (WFC) screen, as the software does not know who you are then. Censoring This software has the ability to "censor" user inputed text. This censoring is done only when entering file descriptions or the body of messages. There are three "levels" of censoring: Simple case adjustment. Removal of non-words. Removal of superlatives. All three are done when entering file descriptions, and only the first two are done when entering messages. Censoring is not done on imported or uploaded messages. It is also not done when importing file descriptions. You, the sysop, may toggle on/off this feature. You may toggle removal of non-words on/off and you may toggle removal of superlatives on/off. If both are toggled off, then case adjustment is also off. If either one is toggled on, then case adjustment is also on. Simple case adjustment is the "correcting" of lower case to upper case. Examples: " i " becomes " I " "bbs" becomes "BBS" ".gif" becomes ".GIF". Removal of non-words eliminates the word completely. The words that are eliminated: "alot", "l8tr", "c00l", "k00l", "gotta". Removal of superlatives eliminates the word completely. Words that are superlatives; excellent, great, super, incredible, etc. are removed. -18- All three are done as the user enters the text. Case adjustment is the only one that is not "demonstrated" at the time. By demonstrated, I mean that when a user enters a non- word in either a message or description, or a superlative in a description, then they will see the word deleted before their eyes--no matter how many times they repeatedly enter it. Of the above, the "alot" elimination seems to have caused the most trouble--those who use this non-word seem to have trouble stopping themselves. Why censor superlatives? If you are an experienced sysop, you know. Users will always try to add a superlative in their descriptions, they seem to feel the need to "sell" the sysop on the upload, this is particularly true of systems where the upload must first be validated by the sysop before others can download it. One can get tired of these non- descriptions quickly. This is one of my favorite features of this software (the other being automatic logging of removed files). Description censoring is not done when the user is the sysop. You may add or alter the various censored words. See the SHORT.TXT file for information on which lines contain the censoring words. Active Active spell checking is a form of censoring. While entering spelling messages, it beeps whenever a word you just typed is not checker found in the word lists. It beeps at the same misspelled words that Grammar Check would highlight. If both removal of non-words censoring and removal of superlatives censoring are turned off, active spell checking will not operate. If you do not want censoring, but want active spell checking, then leave one of the censors toggled ON, and clear out the SHORT.TXT entries for it (so it finds nothing to censor). Active spell checking can be turned on and off by the user, but it still requires that you have censoring ON to work. Search Another form of "sort-of" censoring is the search string string chopper. This occurs after a user enters a search string to chopper search the "off-line" lists--either from the search lists command, or from the search-lists-before-uploading command. Our first attempt to censor begins by presenting the user with a 10 character field for them to enter their search string. The purpose of this limitation is to remind them that they are searching for text, not filenames. After all, -19- filenames do not really mean anything--they can change from one BBS to another. I like to think that when they type FILENAME.Z and find that they cannot do the "IP" that their brains realize that maybe the filename is not such a good search. Then we do some visible editing of what they typed. First we chop off anything after a "."--any extension. Then we clear out any non-alphabetic text--like numbers and stuff. Things that really only appear in file names. The sysop has a toggle to control whether the software should do this or not. For instance, however, "X00" would become just "X" and not searched for--but "XX_1094.ZIP" would become just "XX" and not searched for either. It is a bit of a trade- off, which is why I left the ultimate decision in a sysop Toggle. Then we check what's left against our list of non-searchable- entries (see SHORT.TXT). Such as ZIP, or GIF--things for which there are just too many entries, and for which a smart user could get a master list of all files on the BBS regardless of their security level. Finally if what's left is less than three characters we just drop it--far too many one and two character entries to be displaying. The system works. Users that continually enter filenames will usually see them chopped down to nothing. Even those that get through will usually produce a warning: "searching for a filename is not recommended." Internal Menus At various times, for various situations, the software will use it's own internally generated menu to offer you, or your users, selections. The colors for this internally generated menus can be defined by you with Settings. These menus attempt to put all the options onto a single screen. To do that, sometimes some get squeezed down a bit. But at some point, they get squeezed down so much they get unreadable. Example: with 200 options, they display only about 5 characters for each. To get around this, the software has a threshold Setting. When the squeezing falls below this number (10 being a good number) we use a vertical selection window instead. -20- CONSOLE KEYS I don't go into them here. They are fairly simple to understand, and once you use them you'll usually remember them. These are just the keys that: lead to more information, are most used, or need some extended explaining. From <alt>d <f10> is the key to remember, it provides help on what the other keys are while you are connected. When a user <f10> is the key to remember, it provides help on what is on-line the other keys are. <alt>h hang up on the user. <alt>c to chat with the user. Hit <alt>c again to exit chat. Hit <f10> for the chat keys' help. You can also just type "cls<ret>" to clear the screen when in normal chat (vs. 2-way chat). To safeguard the integrity of other routines, this only works from the menu's. <alt>k to delete the current caller when they log out. I like to use this as a quicky way to get rid of callers whom I know I will be getting rid of later (like those who call using handles like "Dan"). <alt>u to do user maintenance. "User" menu command. The caller does NOT see anything, and any keys the caller types are executed after you exit the user editor. You can make changes to the current caller, or any caller, and those changes will be immediate. To safeguard the integrity of other routines, this only works from the menu's. <alt>x to do an immediate exit to DOS. This does not save anything. It only works when you are logged on at the console. Does not take the phone off the hook. You can use this command anywhere--but because it does not update the active users record (which is usually you) it is best to use it from WFC. <alt>s to shell to DOS. Does take the phone off the hook. <alt>z This is a cross between <alt>x and <alt>s--it exits the BBS quickly from anywhere without saving anything, and takes the phone off-hook. See <alt>x above. <f8> Accesses NOTEPAD.TXT--letting you send any lines from this file as if you typed them at the console. <f5> toggles the screen (a screen clearing is done) between 25 and 50 line modes. VGA is required for this. <alt>p Pure mode. Direct access to the modem command -21- mode. This is mainly useful with sysops who call using <alt>d. If you wish to show them something, or explain problem, then you hit <alt>p on your end, and they hit <alt>L on their and, and you will immediately be able to log in on their BBS (rather than you calling, it's their "dime"). Increasing the callers SL allows you to do sysop things from the console while another user is on-line, such as allowing you do demonstrate the sysop capabilities to another user. When you are in a DOS shell (such as using <alt>s--which can be used from Chat as well), two useful commands are: "DSZ rz" and "DSZ sz filename.ext". The first receives files the person at the other end is sending, and the second sends "filename.ext". Both assume comm port 1, and you may need to change to the directory with DSZ first. See also: THE "WHO'S ON" STATUS LINE Definable You may define <ctrl>F1 to <ctrl>F10. See SHORT.TXT. These lines can contain the menu commands you wish to be executed when you hit <ctrl>Fx keys. You aren't restricted to 4 letters. These control sequences will be allowed from anywhere, so be careful. This is an extremely powerful, dangerous, and unpredictable ability of the software. It relies on you to know when a menu command should or should not be executed--especially so when a user is on-line. They are probably best used to call a door from the waiting- for-caller screen (hint hint). Because you may enter any menu command, and do the command at any time, you can see how problems can arise. Particularly important to not do: user commands when no user is there for the software to find or update (such as at the Waiting-For- Caller screen). Only trial-and-error will let you know when to use that key to do what you want, and when not to (ie, the system crashes). I have predefined <control>F2 as the "MCED" command (McEditor). Very useful when you design yourself into a hole in your menus. -22- I have predefined <control>F3 as the "MHlp" command (Menu Command Helper). This is the "H" from within McEditor and provides you with full screen access to information about the various menu commands. Useful for browsing and re-confirming the functionality of a command. Some commands probably will not work if the current comm port is not zero (because the software does not detect a carrier signal on the current port). You can get around these by using "PORT". For example: "PORT _0 ABCD PORT_1" which first changes to comm port 0, executes command "ABCD", then changes back to comm port 1. See also: MENU COMMANDS Misc. The way the program works is like a hub and spoke system (such as a large city in relation to the smaller cities around it). Menus represent the central hub. From these you go to many sub commands. This means that most commands are sub commands and not part of the main hub. So, for safety's sake, you should only execute console keys (such as chat, or <ctrl>Fx's) from the menus when a caller is on-line. The concept is that you can go to the sub commands from the main hub, but you should not jump from sub command to sub command directly. For you programmers: even though Basic has re-entrant capabilities, exploiting them by jumping from sub to sub without going through the central hub (Dispatcher) could conflict with the global variables and distort them. Thus leading to unpredictable and potentially disastrous results. However, Basic is very robust, and usually you will have to be pretty unlucky for anything bad to happen. The "dinky" stuff, such as <alt>h or beeping, you should not worry about. It is the chatting, shelling to DOS, running a door, etc. that are likely to cause troubles for you if you execute these "inside" a sub module. -23- LOGGING Both the Callers log and the Errors log can be limited in what they show using Logging Toggles. These logs are all standard text files. Feel free to simply delete them whenever you feel like it. See also: TOGGLES Callers log This has the file name CALLERS.LOG. The callers log contains 3 types of data lines: user, file, and system. The system lines all start with a "|=", and contain informational messages from the BBS to the sysop. Users cannot see these lines. The user lines begin with the date and a user's name. For all users to see, it is mostly who logged on when. The file lines come straight out of the protocol log files. They do have any paths stripped out first. You can toggle these on/off in the File Area Definitions. When listing the log, users are shown the user lines and the file lines. When the sysop lists the log, he is shown all lines. From the information shown, users can deduce the following: ∙ Who called, when, and from where. ∙ Who upload files--in case they would like to contact the uploader with a question. ∙ Who downloaded files--to see if a friend downloaded a file (saving them the trouble) or to see what kind of download interest their own uploads have gotten. ∙ Who lost credit for duplicate/bad uploads. ∙ Who passed, or failed, Peer Review. It is also useful for other sysops, they can see who are good users and who are bad users. Perhaps leading to increased access for these good users on their own board. Technical note: when you list the log using an external list utility, note that the user who did the actions comes after what they did. That is, when using something like LIST, the user that did a file transfer is listed after those file transfer entries. The file should be read bottom-up. When using one of the software's internal log lister's, this is taken into account and is listed correctly with the person's name first and their actions on the following lines. -24- Errors log This has the file name ERRORS.LOG. This log contains important error messages, or unimportant minor adjustment notices. ** IMPORTANT ** When you have a problem, you should check here first to see if it might have helpful information. ** IMPORTANT ** Session log This has the file name SESSION.LOG. The session log is an I/O trap log, and will contain the I/O exactly as it was sent and/or received--including all the ANSI codes. There are useful sysop commands to slow-view these ANSI files and to strip the ANSI codes out of the file. Chat log This has the file name CHAT.LOG. The chat log contains the trapped chat sessions. EH? Are you still reading this without trying the program? Now would be a good time to try it out, otherwise the detalia in the following sections will become confusing. -25- LOGIN The login sequence begins from the time of connect (when we usually display a logo or somesuch) until we display the main menu. This is referred to as the "Login Loop of commands". At any point during the login sequence, the sysop may define that one or more ANSIs be displayed. The sysop may also add or delete various other capabilities (such as news) that can appear during the login process. User Names You can use just about anything for the login name. Examples: "|017th |15Guest", "Jo├┤N rOhNΣr ]I[" But it does make its own intelligent changes: "john rohner" -> "John Rohner" "JOHN MCADAMS" -> "John McAdams" "john Doe" stays the same. When logging in, a caller may start their name with "=". Example, "=John Rohner". What "=" does is disable auto-name- detection. This is useful for users that use scripts, since with auto-name-detection their "key sequence" that makes up their name, may change from login to login if a similarly- named user is added, or deleted, from the user list. Auto-name-detection at logon always gives me a good chuckle. This occurs when a new user calls the second time, and types their name, with the software producing half of it. They just pause, and you feel the disbelief they are undergoing, "How the heck did the BBS know that...". If the caller just hits [Enter] for their name, then auto- name-detect is immediately turned off (without bothering to tell the caller). If the caller just hits [Enter] for their password, and it is not their password (yes, passwords can be nothing) then the software will turn off auto-name-detection. Users now REALLY have two names: a normal name, and a Real name. The normal, usually the alias, is what's seen. However, the Real name is now so real, that the user may logon using either (normal name will be displayed). When listing the users, both normal and real name will be shown as users. It was necessary to do this, as the ability to change names, IEMSI, and other real name stuff (like stopping duplicate names) requires that I mix real and alias/normal names in the index. -26- For this reason, "List Users" will show both names (real and normal). So if you require real names, but yet your users are paranoid about others finding out the real names, you could either put the real names into Sysop Notes, or disable the "List Users" command. Also because of this name duplicity, it will also wrongly show the number of active users in the stats. Login (cont.) If the user has defined a logon note, it will be shown during the login process. If the caller has any unread mail waiting for them, they will be given the option to read it at login. If the caller has multiple messages waiting, they may select to Scan the messages (hitting "s") which gives a single line of information about each message waiting for them. Multi-node limitation: the login system stops the same name from logging on multiple nodes. The exception to this is the sysop. The reasons for this exception: because <alt>x still leaves your name as "logged in" on that node which makes it tricky to log back in. The second is that it's assumed (perhaps wrongly) that the sysop knows what the heck he's doing. We stop users because their records would get all tangled up--but I should be fixing this in the future. Technical note: if you do something to a user on node 1, while you are on node 2 (such as give higher SL, or send a message to), it will not occur. I would call this a bug, but it occurs because that user's record on node 1 is stored in memory, so if we change the record on disk, it does not check for changes before re-writing the user's record back out when they logout. When I fix this, then I think allowing the same user on multiple nodes will be possible. New users will be asked for their screen size using a rather odd method: we output 50 lines with numbers and ask them which they see at the top. We do this because "viewport" size is crutial with this software--it tries to use the whole screen. We do not want to be confusing the user by asking for a screen size--to which he might enter 25 when all he can see is 22 lines. See also: MENU SYSTEM, LogN, Welc, STRT -27- READING When you select a reading messages command from a menu you MESSAGES will be given the range of message numbers and the number of new messages. You will be asked to enter a message number to start at, or type "N" to start at the first new message. The exception to this is when logging in and when reading Private Mail (if you are not a Message-Op), then it just displays the first appropriate message to the command (such as first new, or first to/from the sender, etc.). A message is then displayed. We use a nice screen-sized window reader. The commands are just what people expect: [enter] for next page, "R" to reply, "Q" to quit, [enter] for next message, etc. But there are a lot of commands available, hit "?" to bring up a listing of the available commands. Header The message's header information contains the following: Current Message Area. Current message's number. The last message number in this area. Who the message was from (and maybe their net address). Who the message was/is to (and maybe their net address). The date/time the message was sent. The date/time the message was received. The subject of the message. If the message is a reply to another message. If the to/from name is an active/current user (toggle). If Net Mail messages have been [sent]. The sysop has a couple toggles to control what is seen. These are set in the Message Area Definitions. If the Message Area is a Net Mail area, and the net address is not zero or your's, then the net address will be displayed. Messages have a counter that is updated each time the message has been read. When the Message-Op of the area reads the message, however, the counter is not increased. This allows you to, say, review Private Mail without a user wondering why his private message says "read 2 times". Body The body area of the message is displayed using user- definable colors. A Message Area Attribute may be set to show "hidden" net information for Net Mail messages as well. The information then shown is: Hidden "Kludge" lines. Such as PID and MSGID. EchoMail "origin", "tear", and SEEN-BY lines. -28- You can move up/down through the message (either one line at a time or by pages) using the arrow keys. [Enter] will go to the next page, until you are at the end of the message, then it will go to the next message. If the software determines that the message is an ANSI, it will display it all at once. This can really mess up the screen if the ANSI doesn't start with a clear screen command. Choosing a black background when reading these messages can help a lot. Footer After the body, is a single (dark) line of information that shows: Total number of replies to this message (toggle). Date message was last read by anyone (toggle). Total number of times the message has been read (toggle). The user has a couple toggles to control what is seen. This line does not appear until the end of the message has been reached. So this is a convienent method for you to know when you have reached the end of the message. Commands The main command is "?", which brings up a help screen. When reading a message from a Scan Messages command (or something else like the Zombie Messages), almost all the commands will not work. I'll fix this in the future. A number may be entered. This is a "jump to number" order. The message in the current message area that corresponds to that number will then be displayed. Deleted messages are ignored. If no message has that number, then the first message with a higher number is displayed. Auto-detect for ZModem and BiModem uploads is also done. If you were the poster of the message, the files will be attached (useful if you forgot to do the File Attach command). If you are not the poster, then we exit to a menu, and the uploads will be stored in the upload area 001 (that is, it will work just as if the person did an auto-detect upload at a menu). After some of the below commands, we move to the "next" message. If the user had been doing "Next" we go to the next message number higher, if they had been doing "Previous" we go to the next message number lower. -29- ? Brings up an ANSI listing of the commands available. For the sysop and co-sysop, a second ANSI listing also appears. The help ANSIs are stored in HELPBLKS.TXT--feel free to change them. [Enter] Display the next page. If at the last page, go to the next message. <right>/<tab> Display the next page of the message. <down>/+ Display the next line of the message. <left>/ Display the previous page of the message. <backspace> <up>/- Display the previous line of the message. Again Read the same message again. Continue This command will allow (only) the author of the message to message continue the message as if they had never stopped. It jumps them right back into the entering message text system. For this to work, the author must have saved the message with "Finish Later". See also: ENTERING MESSAGES Delete Delete the current message. Only the sender, receiver, or Message-Op may do this. If the message contains file attaches, the software will ask for a confirmation. The user also has a toggle to confirm the deletion of each message. Edit You may edit/alter an already sent message. It is simple search and replace. You give it a string to search for, and a replacement string, and it does it. For historical accuracy, the replaced text is never "really" replaced. Editing gives you an opportunity to clean up a message. But it also offers an opportunity to "rewrite" what you said. To stop any kind of abuse: the original text has a backspace character added after each character--too fast to notice when reading, but noticeable in backscroll/capture buffers. -30- Example, I have the message "Howdy, thar!", and decide to edit out "thar" and replace it with "there". When reading, it is seen as "Howdy, there!", but in the backscroll buffer you might see it as "Howdy, t▓h▓a▓r▓there!" depending on what type of communication program you are using. Historical accuracy is maintained, while giving the ability to alter already-sent messages. Only the sender, receiver, or message-op may edit it. Forward You may forward the message being read to another Message Area or another user. A note, "Forwarded from" is added to the top of the message. A sub-note may attached to the top or bottom of the message. This is useful for explaining why the message was forwarded, or to add a comment before sending it onto the next person or Message Area. Only the sender, receiver, or Message-Op may forward a message. The current Message Area must not have the don't- delete Attribute set. Technical note: Message Area Attributes, such as always-use- ANONYMOUS or always-use-ALL, are ignored. If the message has normal TO/FROM fields, then if moved to a Message Area with those special Attributes, it will still contain the normal TO/FROM fields, rather then be given the "FROM: Anonymous" or "TO: ALL" to which that area normally demands. Get files This option is used to download files that are attached to the message. If you are the author of the message, it goes to "Give Files" instead of this. The files successfully downloaded are subtracted from the user's can-download bytes and daily time stats--unless they are "(Free)". If there is only one file attached, it will begin sending it. For more than one attach, it will ask you to select which ones you want. The files are subtracted from the user's can-download bytes and daily time stats. This is done for all the files attached to the message, and regardless of whether one or more of the files were successful or not. That may sound strict, but it helps discourage use of the file attach system as an upload system (for interpersonal uploads). -31- Give files This option is used to attach files to a message. If you are not the author of the message, it will instead do a "Get Files" command. The author can use this command to continue or add to the uploads related to a particular message. This command is mainly useful for finishing <incomplete> file attaches. A "Continue Message" for file attaches. No upload crediting is done on file attaches. The author need not have specified "Files Attached" when originally writing the message for this to work. Next Read the next message in the message area, or move onto the next message area if reading mail at login or using the "Read All New Mail" command. Previous Read the previous message in the current message area. If reading mail at login, or using the "Read All New Mail" command, and there are no previous messages, it does not go to the previous area, but exits the reading of messages. Quit This will quit reading the messages. If you are using "Read All New Mail" it will quit the current Message Area, and go to the next area. Reply Enter a message in reply, to the sender of the current message. View a file This command will display a file attach. Nothing fancy is attach done, it simply sends the contents of the file. This is extremely useful sometimes. It allows a user to post a message greater than your line limit (or 16k). You could maintain a small library of text files in a message. Disadvantages with this are that you cannot quote from the file, and it relies on the formatting of the file rather than then internal word wrapping/etc. formatting stuff. If there is only one file attached, it will begin showing it. For more than one attach, it will ask you which one to display. The software will automatically not view the file if it is an archive. -32- eXit to menu This is the same as "Quit", except when doing a "Read All New Mail" it quits that too. Sysop Commands Where is says "or Message-Op" above, it means it--even the sysop is excluded. But, of course, it is the sysop who changes who the Message-Op is. Anyways, Sysop's and Co- Sysop's have their own commands. Neither users nor Message- Op's can do these. U User Maintenance Access User Maintenance to edit users. S Show Hidden Info Toggle Show hidden Net Mail information. & Msg --> File Store a copy of the message to a disk file. ! Msg --> New Msg Area Move this message to anther area. @ Edit Msg Info Edit this messages' header. > Move All File Attaches Move the file attaches to another directory. # Kill All File Attaches Delete the File Attaches. ^ Re-Inform User Re-inform the receiver about this message. * User & Msg --> Peer Review Send the user to Peer Review processing. / AI's "Go Fish" Reply Give a standard sysop reply ("look around for yourself"). <alt>1 PGP Decrypt: View Decrypt the message using the Sysop's key, then view it. <alt>2 PGP Decrypt: Re-Save Permanently decrypt the message using the Sysop's key. Of the commands above, a Co-Sysop cannot do the following: Msg --> File Move All File Attaches Decrypt Messages The software's "AI's Go Fish" sends the user a quoted reply of their message, and adds a note that they should look for -33- the information themselves. The message is sent from the AI. The original message is deleted. The text of the reply is stored in TXT_BLKS.TXT block number 13. You may edit it to your liking. The Peer Review processing is part of the Peer Review voting- on-a-user system (explained later). This command will send the message to a special message file, delete the message, and then send a prepared AI reply message to the user. The user "undergoing Peer Review" Attribute "0" is also turned ON. The special message file is a Peer Review MESSAGE.P## file, from which users participating in Peer Review will get the information to make their voting decisions. If you execute this command when the user already has a Peer Review file, then this message is appended to that file--to provide further information for reviewers. The "re-inform" command will "re-flag" the user of the TO: field telling them they have a message. This command is useful after you have accidentally deleted your USERMSGS file--since rebuilding it sets all pointers/etc. to zero-- this should be used on all "(Rcvd: -NO-)" messages. It is mainly only used for when something goes wrong. But you can pester the user by re-sending a message they may have ignored also. Misc. If the sender of the message had included File Attaches, and you respond with "Peer Review" or "AI's Go Fish", than these File Attaches are deleted as the original message is deleted automatically. When you move a message (either with the sysop Msg-->New Area command or the Forward command) the message will be given the next message number appropriate to that (destination) area. If a message has File Attaches, they are kept intact and with the message when you move it around or re-edit it, or even Continue Later it. -34- ENTERING Leaving messages is a two step process. The first step asks MESSAGES you about the message attributes: subject, whether to quote, etc. The second step handles the entering of the message text and the various entering messages commands, most notably: saving. During this first step, entering of information, you select the first letter of what you want to do/change, and then [Enter] alone to move on to entering the message's text body. All of the various "objects" on the screen are active commands. Hit the first letter of the object name (eg. "T" for "To") to alter that objects data or state. However, some of these options may not work--either because of the type of message, type of Message Area, or with each other--then you will get an informational note saying it cannot be done. Heading Line The first thing displayed is a heading line. This line contains information about the type of mail to be sent: Public, Private, Anonymous, and Net. Because there are only two types of "From:", the posters name or Anonymous, there is no "From:" field shown. Attributes in Message Area Maintenance define what type of an area it is to be. So if when posting a message you see that this heading information is wrong, you should recheck your Attributes for that area. In This is the name of the message area to which the message is being posted. This command option can be used to move the message to a different Message Area. Only those areas which the user both has toggled ON, and access to, are offered. To To whom you wish the message to go. For replies, this is given the name of the poster of the original message. If the message area allows it, "ALL" can be used. If the message area is an EchoMail or NetMail area, then any name be entered, otherwise the name entered must be that of an active user. Entering "Sysop" will expand out to the message-op of that area. Entering "Fellow" will change to "All", which then changes to "Fellow Sentient Beings" (you can change this, see Settings). -35- You may use "*" or "?". This will bring up a list of the first 20 names matching the characters you have entered so far. Subject The subject of the message. For replies, this is forced to be the same as that of the original message. The subject field of a message is a variable thing--it depends on the type of text you type. This is because the message subject's text is compressed. If you type a long subject, and the system "deletes" characters at the end of it after you hit [Enter], then you know some of subject has just been deleted because it turned out to be too long. Usually only occurs with subjects that are all uppercase characters. Any leading spaces are trimmed off. At This is the NetMail address to send the message to (if the area is a NetMail area). Hit a "?" to get some help on what to enter. Merely hitting return will set it to zero--making it a local- only message. The net address supports the Fido format, which is xxxxx:yyyyy/zzzzz. Where "xxxxx" is the zone number, "yyyyy" is the net number, and "zzzzz" is the node number. But you can type "x.y.z" or "x y z" or most anything and it will work. The software uses your net address to fill in any missing information. That is, if your address is "a:bbb/cccc", then entering only "##" will be converted to "a:bbb/##", and entering "##/##" will be converted to "a:##/##". A private message without a net address in a Private NetMail area will be, instead, correctly put into Private Mail area (001) instead. You are able to send messages to net addresses not in the sysop's nodelists, but there is no guarentee these messages will reach their destination. Besides Fido-style addresses, you can enter Internet style addresses (name@domain.site, but actually anything). The software will properly store these addresses with the message, but at this time does not use them for anything. There is a Message Area Attribute to turn this on. -36- Line numbers This toggles ON/OFF whether you wish to see line numbers at the start of each line when entering the message text. It is very tricky to edit a message without line numbers. But turning line numbers OFF allows one to put more text into a message, and makes large ASCII sends (from caller) of text more reliable. Quote original This will quote the entire original message when doing replies. When entering the body of the message, you may then use Delete to remove any quote lines you do not want, and Insert to insert between quote lines if you want. You cannot upload a prepared message and quote the original at the same time. Upload message Upload a prepared message. You will not be allowed to select this option if you already have selected to quote the original message. The uploaded file should be a standard text file. Not compressed, nor any other weird characters (those below ASCII 32). ANSI codes and graphics characters are allowed, but it would be better for everyone if they were File Attached. When this feature is used from the console, it is called importing. You will then be asked for a pathname to load in as the message. The original file will not be deleted. Processing includes truncating any additional lines beyond your set maximum number of lines allowed in messages. Normally that is 98 lines. This command can be used to import/upload text files and .REP packets. However, if the console does import a .REP it will be deleted after importing. Uploading/importing an ANSI for a message (or part of a message) is easy. Just remember: no ANSI line longer than 78 characters--word wrap does screw up long ANSI lines. File Attaching is usually a better solution because it lets one attach very large ANSIs and allows the user to download the ANSIs intact if they want. When uploading an ANSI, only the maximum number of allowed lines per message are imported from the file (usually 100 or 200). After uploading, the screen will look horrendous, just ignore it and do Save right away. See also: SETTINGS, MsgD -37- Carbon Copies You may send multiple copies of private messages to many users. These are known as CC's. When you save the message, the software will ask you whether you wish to include all these names at the top of each message, or not. You are not able to send CC's in NetMail, EchoMail, or with File Attaches. File Attaches Select this if you wish to attach files to the message. When the message is saved, the software will ask that the author upload the files to be attached. Or, if at the console, the pathnames you wish to duplicate and attach to the message. Files Attaches are stored in the MSGSTUFF directory. Each message with files attached will have its own directory under the format: MessageNumber.Area Example: Private Mail (area 001) message number 5000 would be stored in \MSGSTUFF\5000.1. You, the sysop, may add or delete the files and/or directory, without concern--there is no internal tracking done for the File Attaches (the directory is either there and contains files, or it is not). If you forget to select File Attaches, or just want to be lazy, then you can "just upload them" at the command line. This will cause the message to be saved, and for it to begin receiving the transferred files and attach them to the message. This does not work from the console. If the upload is aborted, or you want to add more later, you can do so when reading the message. You cannot do File Attaches with Carbon Copies. Only the sysop can make the File Attaches free. Reception This will drop you a short message confirming that the person Report received and read this message. This can only be used with private messages. The RR is sent when the user reads the message on-line (usually at login), but not if (for some reason) they download it (like in a .QWK packet). -38- Encrypt This is a sysop-only command that will let you encrypt the message with PGP. For this to work, you must already have the public key of the person to whom the message is TO: on your PGP key ring. See also: PGP.HLP Do A Freq This command allows the sysop to do FREQ's (File Requests) from other BBS's via Net Mail. The actual FREQ attempt will be done when the sysop calls manually with <alt>d and hits <end>, or the next time the BBS calls that BBS number for a normal net mail exchange. You may do a "crash" (immediate) version of this command from the waiting-for-caller menu. See also: NET_MAIL.DOC Net FAs This command allows the sysop to Net Mail files without needing to make them File Attaches as part of a message. Like "Do A Freq", the actual mailing of the file is done the next time your BBS calls their BBS and exchanges mail. You may do a "crash" (immediate) version of this command from the waiting-for-caller menu. See also: NET_MAIL.DOC Body Entering of text is straight forward. Quoted text shows up bracketed. Hitting backspace can go to the previous line. Cursor movement keys (up, down, left, right) are converted to backspaces (up, left) or spaces (right, down). There is no moving about the message with the cursor keys (yet). With the exception of the cursor movement codes, ANSI codes are allowed in messages. Technical note: These cursor movement keys are "[A", "[B", "[C", and "[D". Now, these codes are a subset of the full ANSI set--so if a user wanted to upload a complex ANSI, theses codes might be part of it and screw it up. But the vast majority of times these keys get encountered are when the user tries to move around the screen to do editing. To use the same codes in an ANSI image as part of the message, one should use: "[1A", "[1B", "[1C", and "[1D". -39- There is trouble, however, with ANSI lines that exceed 78 characters. So, while ANSIs are best in single-line form for menus, for messages they need to be in multi-line form. TheDraw can handle both forms. To put ANSI codes into messages remotely, you must either do an ASCII file send of an ANSI file, or upload that part of the message as a message upload (then the cursor movement keys are allowed in the ANSI). ANSIs jumping all over the screen using either positional or cursor movements keys is simply not the way to do in-message ANSIs. The proper way is to design your ANSI to display a line of ANSI text/drawing, do a CR/LF, then display the next line of ANSI text/drawing, etc. until done. Like sending ASCII text, but with hidden ANSI codes. Quoting of text with ANSI characters can mess up the quote brackets' appearance--unless one follows the guidelines above. Graphics characters (ASCII codes above 127) are also allowed in messages. Exit to the command line by hitting enter twice. One may also type: /s, /es, /post, or /exit at the start of a line to immediately save and exit the entering message process. All the commands work alike. Hanging up saves the message (as "Finish Later"), but loses the line being worked on. If a user has toggled active grammar checking to ON, then each word is checked as they enter it, and a beep is sounded when that word is not found. User's should not have this option ON when doing an ASCII send of message text from their communication program's buffer or from a file at their end. This is because the beeping might screw everything up-- although I suspect it may be OK if both of you are using modems with MNP 4 or better. A //G may be typed at the start of any line to toggle active grammar checking from ON to OFF, and vice-versa. The "G" must be in upper case. See also: KEYS.HLP Command Line Besides the commands below, auto-detect for ZModem and BiModem uploads is also done. Doing an upload in the middle of a message will not destroy the message, and it will be saved before starting the transfer. -40- Users may set toggles to determine if the total number of words, lines, and/or characters should be shown. Similarly for time to enter the message and a Characters-Per-Minute rate. Editing by line number is much more difficult when the user has "no-numbers message entry" toggled to ON. % Save the message to a message file. Only the sysop may do this. But there is a Toggle which you can use to let Message-Op's do this also. The message body is then stored in a MESSAGE.### file. Which then can become part of other messages via the %%%### command. You could rename the file to something like MESSAGE.MJR, and then just use "%%%MJR" anywhere in a message. These are particularly useful if you have a fancy "signature"--easier to do a quick "%%%xyz" when entering a message at the end of a message than a complex signature. When we export the message to .QWK or via net mail, these "%%%"s are expanded out first. Abort Aborts the current message. No message is sent. If you entered more than 80 characters or so, you will be asked to confirm that you really want to abort the message. Continue This lets you continue your message from the point where you entering left off. Delete lines Use this to delete a line or a block of lines from your message. Edit This option will search for an exactly matching string in the message, and replace it with another string you supply. This is the command to use for fixing up typos in the message. Finish later This will save the message as a special "I want to finish it later" message. What this means is that when you (the author) again read the message, you will be able to "Continue message". Selecting this option will let you continue the message, edit it, etc. just as if you had never stopped. -41- After saving, the author can still (or not) upload any File Attaches if they wish. The message is saved--and actually sent. If the receiver logs on before you have finished (at a later time or date) then they will see it as a completed message. In theory, anyone could just use this instead of Save to save all their mail. Then later modify what they said in the message, and proclaim "that is what I said originally". The defense for this is that the original message's text will appear as orphaned text when you purge. This command is not available if the message has CC's. Grammar check This does a spell check on your message, and offers you the opportunity to correct the misspelled words. When a word is not found, and the user hits [Enter] when asked for the corrected spelling, that word is put into your WORDS.NEW file. This file will be utilized in the future when I add the ability to update the WORDSx.DAT files. While it is checking, hitting [Enter] or any of the valid entering messages command keys will bring you back to the command line. Insert lines Use this to insert text into your message. You will be asked which line number to insert before, then it will allow you continue using the normal message entry system. You can insert into quotes to produce the "quote-reply-quote- reply-quote-reply" type of message. List This lists your message, including line numbers. Colorization codes are not acted upon, but simply displayed. While it is listing, hitting [Enter] or any of the valid entering messages command keys will bring you back to the command line. Preview This displays your message exactly as it will be seen by others when reading it. Colorization codes are acted upon. None of the reading messages commands will work, although "?" will still bring up the help screens. -42- Save This compresses and saves the message. The software has the ability to maintain a text file of all messages added to the Message Area (see Message Area Attributes to turn it on/off). When the message is saved, it will be appended to this file. This feature is useful for providing a way for whole message areas to be downloaded or FREQ'd (rather than using the Message Downloading/.QWK system). -43- MESSAGE FILES Using an editor (or the "%" command) you, the sysop, or whoever you designate as the Message-Op (for an area) can send messages that include a special "load message file" command. This command, "%%%" when embedded within a message, will cause the software to search out a file and load it into the message when reading. Message files start with the name "MESSAGE." and contain a 3 letter extension ("xxx", so "MESSAGE.xxx"). It provides a method of sending lots of identical letters while using a minimum amount of drive space. Basically all these message files contain is text. You may create, or alter, these files with any standard text editor. Even put in ANSI codes. Usually, though, you will just create the message and use the "%" command to save it to a file. With this method, the computer increments file extensions ("###") from the highest found (example: if you have MESSAGE.009 then MESSAGE.010 would be created). However, you may re-name these extensions to any three characters you like. Message files should not exceed 8,192 bytes in size. To do so is risky since it relies on string space. Inserting a message file into a message is simplicity: "%%%xxx" anywhere inserts the message ("xxx"). They do not need their own line. They can be in the middle of a "word": "You should%%%xxx.". They can be recursive--the file messages may contain "%%%" codes themselves--warning, the system does not protect you from looping, which will crash the system (looping: xxx contains reference to xxx, or xxx contains reference to yyy and yyy contains reference to xxx, etc.) The system only expands the "%%%" codes into messages if the message was sent by: the AI, the Sysop, or the Message-Op for the area. Any other authors and the reader will see "%%%xxx". Similarly for message files that are not found, "%%%xxx" gets displayed. This allows you to use "%%%%%%%%%%%" without worrying, and users cannot find out your message file contents, nor use them in their own messages. Mass Mail uses these to send letters to users of a defined Security Level value. You also use this to configure a message to be sent to new users (to introduce them to you, the BBS, and the interface). There is nothing stopping you from creating the messages on- the-fly and just using the "%%%" codes instead of re-typing large blocks of text. -44- The "%" command lets you use the message entry system as a text editor. However, remember that messages are divided up by "paragraphs"--a paragraph is text followed by a CR/LF (an [Enter]). Remember, text is word wrapped. So if you edit the file, you will probably see lots of lines that extend past column 80. If you do choose to edit messages externally, I recommend only using CR/LF's where necessary, let the software do the word wrap (really, you just need to follow the same advice as Uploading/Importing a message uses). Normally only the Sysop and the AI may send messages with "%" codes. However, you may change a Toggle to also allow all Message-Op's to also send messages with "%" message file codes. %%%LOK is a special order. It will set the user's locked-out attribute, so that when they are done reading messages, they will be hung up on and locked out of the system. The "%%%LOK" command is ignored until the name logged in matches the TO: field of the message. This allows you, or anyone besides the person the message is to, to safely read the message. With any "%%%xxx" command, three stages are done: first we see if there is a MESSAGE.xxx file to display, if there is, then we show it. Second, if no MESSAGE.xxx file exists, we see if it is a special command, if it is, we do the command if possible. Lastly, we simply display the "%%%xxx" because we cannot do anything with it. A serious draw back with this: one can never remember which MESSAGE.xxx contains what. In a future release, I will extend this to support "%%%pathname". See also: SETTINGS, TOGGLES -45- RAMBLINGS Ramblings are both message files and text files. They contain messages stored in text file format. Users append messages to the end of these files. Unlike regular message bases, however, these utilize the same NewFilesPtr system as files do. After each logon, all formerly new ramble entries become old. Anyone can add to a ramble. Anyone above a defined SL may create a ramble. The creator may even restrict access to the ramble by a SL (SL restrictions higher than that of the users own are not accepted). Only the creator of the ramble, or the sysop, can delete a ramble. Any ramble files containing new entries are highlighted. Technical note: Ramble file information is stored in RAMBLING.DAT, and ramble message text is stored in RAMBLE.### (001 to 996). More than 996 will merely overwrite 001. While a user cannot upload a message in file form (like they can with the message system) they can do an ASCII send from their end to send up a prepared message. The ramblings menu has a statistics/title toggle option. The statistics are useful for finding new messages if you have not checked in on the rambles after a few calls. When reading rambles, you can elect to read the whole thing, just new entries, or jump past a specified number of entries before reading. Rambles are meant to be foot-loose-and-fancy-free. A wide open system for quick exchanges along a single topic. It works best if you give can-create-rambles access all users. See also: SETTINGS -46- FILE AREA There are two ways to list files in the File Areas: the CONTENTS normal paged system, and a Point & Shoot system. LISTING File areas to which the user does not have access are not shown. The area numbers (1..n) that the user will see is adjusted properly (if you have 4 areas and area #2 the user has to-low a Security Level value for, they still see 1, 2, 3, not 1, 3, 4). Paged System What I reference below as "the file system" is that part of the software where files and descriptions are displayed for a File Area, and which users may select to download. This section does not deal with the commands to get you into the file system, merely on the file system itself. Firstly, you must remember that the file system is far more powerful than any other ever invented. Most BBSs are happy just to display a FILES.BBS file that is stored in that File Area's directory. This software's file system not only lets you seamlessly fold multiple directories into a single File Area, but it lets you define both the File Area header and how the file description lines are to be displayed. These too are covered in other areas of the docs. In the file system, the AI does a lot of management for you. Discovering and removing and fixing file entries. It tells you what it is doing at the top line of the screen (only the console see's this). So powerful is it, that you could scramble all the files on your HD--putting them randomly into different areas, and (after listing all the areas) your entire on-line file lists would again be 100% accurate. When it discovers a file, use uses the AI face for uploaders name. But don't worry about this, it's automatic. The display As mentioned you will be able to configure the header line(s) and the description line(s). You will be able to do this for each area individually if you want. This is explained later in the docs. Right now, I want to cover some of what you will see. The number of lines of files/descriptions displayed depends on the users defined screen size. As usually, if you did not start the program with /USEVGA the screen may look weird on the console when the user has a > 25 screen size. Just ignore that. Files have a file selection letter displayed next to them. This is "A" through "Z". If we reach "Z" before we fill up -47- the screen, we stop displaying entries at that point. Example: this happens a lot with GIF areas and > 25 screen modes because GIFs usually only have one line. For normal File Areas, enough of the files have extended descriptions that this rarely occurs. This method was considered better than using numbers (1 to 50). When displaying the last file, if it has a long description that doesn't fit, we display what we can, and when the user goes on to the next screenful of files, this file will be the first one, and it will have its full description displayed. This method was deemed better than not displaying the file (leaving blank lines at the bottom) or truncating the description and not displaying it on the next page. New files are automatically highlighted to bright white. If a file has some Attributes, they are displayed using the following four letters: f appears if the file is free. g appears if the file is a group-specific-only file. i appears if the file is invisible. Only the File-Op or sysop will see the file entry. p appears if the file requires a password to download. When listing "new files", the files are sorted newest to oldest with the newest one being on top. They are also displayed by area. When listing for files containing a search string, they are listed newest to oldest (newest at top), and in a single-area like format. The display uses area #1's defined Form Type. Command line There are usually just two command lines, one that says "Option, ?, or [Enter] to move on:", and some question asking for a file name. During many of the options below, a user may type the single letter rather than the filename for files that were listed on the screen. They may also enter file names for files that are not displayed, and in any File Area to which they have access. From the main command line: "?" will bring up a list of commands. -48- [Enter] will display the next page of files, or, if at the end, go to the next File Area and display its first page of files. <up>/<down>/-/+ can be used to redisplay the files either moving down one file or back one file <left>/<right>/<bksp>/<tab> does the same, but instead does it a page of entries at a time. You may also simply type a number, and we will jump to that area and display its contents. Including the number of the current area, for which it will simply restart drawing from the start. Auto-detect of Zmodem and BiModem uploads is also done. User commands The following is a list of the commands anyone may type. For the most part they are self-explanatory. Quit Stop listing files and exit the file system. If the user has anything waiting in the download queue, they are asked if they want to download it. Next Area Moves the user to the next File Area to which they have access. If we are at the end, we exit the file system. If the user has anything waiting in the download queue, they are asked if they want to download it. Previous Area Moves the user to the previous File Area to which they have access. If already at the first area, we just restart and list that area again. Redraw This command simply redraws the screen. Useful if it gets too cluttered when adding files to the download queue. -49- Extended File Info This turns on the showing of the extended file information lines. These lines are usually one or two lines for each file that contains information such as who uploaded the files and the date it was last downloaded. Some File Forms do not have extended information lines, but you can always add/change them yourself. This is a toggle command, and when selected it will redraw the screen. It is kept ON until you go to another area, or again toggle it OFF. Work On Archive This will let you access the contents of archives. Things you can do include: List the contents of the archive. Display text files in the archive. Download files from the archive (user ratios do apply). Test the integrity of the archive. List From A Point On This is a very useful command when there are large numbers of files in an area. It asks you for a letter, you type one, and it starts listing the files in that area from that letter on. Upload This will let the user upload to the current area. If the area does not allow uploading, it will try to let them upload to area #1 instead. After the upload, we return and redraw the screen. Add To DL Queue This command lets users add files to the download queue. The current contents of the queue are displayed, and each file they add is also then displayed. Their current can-download bytes and minutes is also displayed, and shows how much is left based on the current files in the download queue. -50- The size of the users download queue depends on their screen size, and once the screen is full they are not allowed to add more files. It does not do automatic helpful exchanges for minute- credits or megabytes (like the menu Download command does) when the user tries to exceed one of the download limits. Contents Of DL Queue This simply lists the contents of the download queue. If there are files in it, the user is asked if he would like to remove any. Download If the download queue is not empty, we first ask them if they would like to download that. If yes, we send it to them, then redraw the screen. If they do not want the download queue, or it is empty, we ask them them which file they wish to download. We then send it immediately. When we download the queue it is then cleared. This is done even if the user aborted the download inside the transfer protocol. Xtra Info This will display whatever information we have on a specific file. Including: uploaders name, date it was uploaded, actual files date, any attributes (expanded out) and other stuff like number of downloads and date last downloaded. Sysop/File-Op The following is a list of the commands only the sysop, or commands the File-Op of the area, may type. "~" to Remove 1st Line This is a handy command. It asks you for a file name, then removes the first description line from that files description. Particularly useful if you allow users to enter descriptions for files with .DIZ's. "!" for File Maintenance This will edit the header information of the file. -51- While editing, the fields are "live"; changing the name will change the file's name, changing its File Area will move the file, setting the delete Attribute will delete it. This command is a bit cumbersome, and I'll be cleaning it up more in the future. "*" to Oust The File Deletes the file. Moves the file name and the first line of the description to ALSO_GOT.LST. If the file is in a "CD" area (File Area Attribute 9 ON) then the filename.ext is added to your EXCLUDE.LST. "@" to Oust The File: Special AKA This is the same as the Oust above, but will create a special ALSO_GOT.LST log line. Specifically, it brings up: FILENAME.EXT aka for: and leaves you just after the "for:" to input something, or zap the line and make it what you want. I use this "aka" system for duplicate files. Files that have been uploaded that actually have another name, and for older versions of files. It helps keep the ALSO_GOT.LST file lets cluttered and lets me know what this file was an AKA for (I usually just input the file name to which this file was an AKA). Example: CSHOW460.ZIP aka for: CSHOW462.ZIP CSHOW.ZIP aka for: CSHOW462.ZIP VIEWGIFS.ZIP aka for: CSHOW462.ZIP etc. It provides me with confidence when looking at an AKA'd filename that yes, I made sure it was a duplicate of something else before I deleted it. Versus simply deleting it out of hand (for which I may later come across it again on a future CD, and again have to check it and find it was a duplicate, etc.--this saves all that work.) ">" to Move File To Area This command lets you move a file to another File Area. Since remembering lots of File Area numbers is tricky, you can do "?" which will bring up a list of your file areas. This list may be paused with [Space] and aborted with -52- [Enter]. It is another thing that needs more work in the future. See also: MENU COMMANDS Auto-delete This software's "auto-delete" capability is curse because it curses works so damn well! Whenever you are in DOS, you can delete files in a File Area, or move the file to another File Area, right? For example, I like to exit to DOS to look at the GIF's, and then toss them into the various GIF areas myself. Upon return to the BBS, I simply list the uploads area, and the GIF areas. When I list the uploads area, it auto-detects that those files (GIFs in this case) that I moved/deleted are no longer there, and it sets their "deleted" attribute. Then when I list the GIF areas, it discovers those that I moved, and "undeletes" the entries. Its simply a lot easier to delete files in DOS when I need more drive space, and let the software auto-fix the File Areas for me. But the dark side of this is that the software does not do two things when it auto-deletes a file entry: it does not remove the entry from FILES.IDX (so if you type in the filename.ext it will still "find" it), and it does not record an ALSO_GOT.LST log entry. We do not do these two things because they take a lot of time (particularly with lots of files being moved) and because the software really isn't sure that you deleted the file (you may have just moved it to another directory, nullifying its work to do the above steps). The first thing, the FILES.IDX entry, is no biggy. If you pack your file entries this cleans it right out--so its rare a user will try to download a filename.ext that is no longer on-line. The second is a problem only if you like your ALSO_GOT.LST file to be accurate--and I do--since users can properly proclaim to have searched the lists, not found the filename.ext, so shouldn't be penalized at all for uploading the non-duplicate duplicate. Although, in a twist of irony, the dupe checker will probably identify it as a duplicate. To get around this logging problem, whenever a file entry is auto-deleted, we wait until we pack the files then we record the ALSO_GOT.LST entry. -53- Thus, if you do somewhat regular packing operations, you should be able to avoid any troubles. Point & Shoot Unlike the paged system above, the P&S system does not do any File Selection "correcting" of errors it finds. It does not list files that and are <incomplete> or invisible. It does not highlight new Information files. It does not display extended descriptions. It does System not do automatic helpful exchanges for minute-credits or megabytes when the user tries to exceed one of the limits. The P&S system also only does about 1/2 the commands, and the number of files it can display from the File Area is limited to the users screen size. Most of these deficiences will be worked out in the next release. But basically what the P&S system offers is a point & shoot system where one can tag and untag files easily, get a good overall view of a dir, and in general be pretty efficient. Movement is simple enough: either the arrow keys or number keys (keypad with "Num Lock" on). To move between file areas use "+" to move to the next file area, and "-" to move to the previous file area. To download files, you must first "tag" them. This is done by hitting the [Space], [Enter], or "5" keys. Tagged files can be untagged similarly. As you tag files, you will be given a summary of how much and how long your download session will be. Hit "/" to turn on the description line. This will give you the descriptions for each file as you move over the file names. Hit "/" again when you want to turn it off. Hit "?" to just give the description for a single file. This is much faster than "/". If "/" is active and you hit "?" than "/" will be turned off also. Use "d" to download the files you have tagged. Unlike the normal download menu option, this one will not do automatic exchanges to help you out, nor does it offer the option of auto-logoff. Use "u" to upload. Auto-detect of Zmodem and BiModem is also done. Unless you do not have access, or the current area is not set up as an upload area, all uploads will go to the current area. Otherwise an attempt will be made to put them in file area 001--if still no access, then you will be rebuffed. -54- "v" will allow you List/View/Test/Extract from that archive. "q" will quit you out of the P&S system. The software maintains a global download queue. The P&S system interfaces this directly. The paged method has commands to use it. There are also menu commands that let you access this global download queue from menus. -55- DOWNLOADING Downloading (and uploading too) requires a protocol driver. Usually DSZ.EXE (which provides many protocols, including the commonly used Zmodem protocol). This can usually be found on any BBS, or just ask the sysop of any BBS to give you a copy if you do not already have one. Users start out with 1 upload byte and 1 download byte--this allows them to get to know the Download system--otherwise they would just get "ratio out of balance, UL first", which isn't quite as enjoyable for their first call to your BBS. The caller will not be able to download if any of their ratios are out of balance. This includes: bytes, files, and post/call ratios. At the downloading screen, callers are only able to enter file names until they reach the end of the line (4 or 5 file names). To do larger "batch" transfers they should use batch downloading when listing File Areas. Wildcard's are not allowed. I have plans to expand this. Technical note: Since the wanted-for-download file names and paths are sent to a file, whatever protocol we use must be able to read in this file. The protocol must accept "@filename.ext" at the end of its command line (where filename.ext is our list of file names-currently it is named FNAMES.CTL). If the user selects auto-logoff, and at least one file was not sent, then auto-logoff is ignored and the user is returned to the system. That is, if auto-logoff is desired, then all files must have been successfully transferred before it will take effect. When downloading, either bidirectional or regular, the software will, through exchanges, try to meet their wishes. If they wish to download a file, and do not have enough time, but plenty of download bytes, and exchange is done for them, giving them enough time, with reduced bytes (if it is possible)--essentially saving the user the trouble of doing with Exchange. Exchanges are not done with regular "daily" minute allotments, but with minute-credits. This is not done with the batch downloading system. Similarly for bidirection. Except the exchanges usually occur after the transfer. If the user exceeds their time allotment, then exchanges are done until they are OK again-- this can mean "borrowing" against the future (negative minute-credits). Should a user with negative minute credits (and few or no download bytes) try a bidirectional protocol again, he will have it limited to whatever his current download minutes are. Should his negative minute credits -56- exceed his daily minutes allotment, then he will not be able to use the bidirectional protocols at all--indeed, he will not be able to download either, only upload. Abuse: It is possible to abuse the system by just logging on, using a bidirectional protocol for three hours of downloading, then logging off and repeating it with another name. For this reason I urge you to restrict bidirectional protocols to users of levels greater than your first ("new user") level. With "validated" user levels, no abuse is possible because ratios are always maintained--even if means that the user had to go into debt. Any imbalance "abuse" (such as doing three hours of downloading) will be handled the next time the user tries to download. The system is designed to be flexible, but a user who tries to abuse the flexibility will, sooner or later, run into a wall--which will require an upload. When a user downloads a free file (as denoted with an "f" in the file listings), the time and size are not counted against them, and do not appear in their stats at all (it is as if they never did it). It does, however, appear in the log files (callers and summary). This is true even if the download is aborted midway. When a download is not completed, bytes are not subtracted from the user's totals--they are only subtracted when downloads have been completed. While on the surface it may seem like abuse is possible (download 90% of the file and extract the remaining parts with "Work On Archives"), in reality it is too much work for a user to consider it worthwhile (they must use PKZIPFIX for ZIP's, they must take time to calculate where to stop, and if they screw up, they must repeat the whole process). I think only one user in two years of operation ever attempted this--I just manually added the bytes to his record, he never did it again. Uploading is much easier to do, and the user needs to have the stats to download the whole file in the first place to even start the transfer. Finally, the Exchange system allows users to maximize their file stats for need: time or bytes--which also has the effect to eliminate complex download abuse. Free downloads using the "FREE" menu commands do not take off time, or bytes. Potentially a user could just do a large free download all day to tie up your system. If this occurs, just make the free file download menu option with an SL higher than that of new users. Ultimately, if you find a user is trying to abuse your system--tying it up, calling and hanging up, etc. Calling the phone company and complaining about harassment is the best way--as the phone company has the calling logs and will -57- be able to see who the caller really is, and prove the pattern of abuse. Password protected files are handled two ways. When the file name is typed at the downloads-file-name-entry-line they are allowed, when the user completes their entry, then the question regarding the password is asked, and they are only allowed to download it if successful. BiModem does not care about our internal password system, it has a system of its own with its own password file, you must put in these entries manually for BiModem to protect your password-protect files and your invisible files (since a user can find the name of an invisible file from the callers log--for long-term invisible's, short term invisible's have a low chance of being seen and are not worth the trouble). This is only for on-line files in the File Areas, other files on your disk are always protected from downloading. Normally, SL protection is done at the "get file name" part of the operation(s). We check DL SL for the File Area the file is in, if not enough access, we pretend it does not exist. However, BiModem has no method to stop a user requesting any file from any of your "BiModem-accessible" defined areas (done with BIMODEM.DIR). Rather, what the software relies on to do this is for you to limit access to the BiModem protocol itself to only those users who can access all your file areas already. Downloading messages (with "Message Downloader") and downloading a Master List (using the internal Master List downloader) are also free downloads (no bytes/time taken off). The why is obvious: its faster than if the user did the same on-line, and therefore should be encouraged. If a user has their "all downloads are free" Attribute set on, then all files are free and no byte/time information is recorded or taken off. You can set it so each download gives the uploader a "commission"--a percentage of the files value. -58- UPLOADING When a user uploads a file, they are given minute-credits and byte-credits. Both of which are exchangeable for the other. Minute-credits allow more time for downloading, and byte- credits allow more bytes for downloading. Minute-credits also allow more time for door games. You may postpone the giving of these credits until after you validate the file if you wish. Or you can credit them a little at a time--it's all in the Settings (and/or also in the Protocol setup's). You may only have one file on-line with the same filename.ext. If the user uploads a file with the same name as one that is already on-line, this is known as a duplicate. They do not receive credit for uploading duplicates, but they will be shown a note that they should leave you a message to get credit. Then, if the file is original, you should rename it, and manually give the user their UL bytes and minute- credits for the upload. Whether your BBS renames, overwrites, or rejects duplicates depends on your protocol and what protocol parameters you use. But in its default settings, we give the file a new name, like FILENAME.ZI1. Normally, uploads will be given a "9" for L&D value, but Targeted uploads are given only a "2". If you disable the L&D system then this does not matter. Abuse: the only possible abuse involves logging on with a phony name, uploading some duplicate junk, downloading what they want, and then next time doing it with another name. This can be avoided by having a complex new user/access procedure, or just requiring uploads to be validated by you first. If a user relies on auto-detect ("just does it") for their upload (for instance, at an ANSI menu), then we will first try to put that upload into the current file area. If no access, we try area 001. If the user does not have upload access to area 001, after not being able to put the upload in the current area, the upload will not be allowed to take place. After a upload is done, there are a variety of post-upload processing that can be done. Including: insertion of BBS comments into .ZIP and .ARJ files, extraction to a file of .ZIP comments, extraction of .DIZ descriptions to your reviews files, and running of a virus checking program. These are registered features, however. See also: SETTINGS, TOGGLES, Protocols, Executable Lines -59- Searching When a user selects a non-bidirectional protocol, they will be asked to enter a search string and a "search the off-line lists" will be done. It is the user's responsibility to make sure the software they wish to upload is not in your lists. You may toggle this requirement (that they search before all uploads) ON/OFF. When searching the off-line lists, a text search is done--not a file name search. When a user enters a string to be searched for, some processing is done: see "Search string chopper" section. These choppings will be shown as they occur--slowed down so the user can see it. If uploading (not when doing the menu command to search the lists), if they hit [Enter] before a search is completed, then it is assumed they do not want to upload, and are exited back to the menu. They need only one completed search in a series of searches to move on to the next step and upload the program. This prevents someone from searching part of the search file, but not all of it. Needed, because the file they wish to upload may be in that part of the list they did not see. If they know the file is not in your list, they can just enter a "scramble string" to do the fastest search (example: AJKLK). The File Area Attribute for "don't include in Master List" also affects the searching of lists when it searches on-line lists (since it uses MASTER.LST)--so you should add the text file of your un-master-listed areas to the search off-line list database as well. Usually, however, you only turn "don't include in Master List" off for transient areas (such as CD's you swap in and out each week, etc.) File Minute-credits will not be given until the user enters a Descriptions description for their upload. This may done later via the Add File Review command. Using the file name as a description is ignored. Holding back of minute-credits is the punishment for users not using descriptions. This software is designed to reduce your workload. If a file has a FILE_ID.DIZ description file, this is considered an acceptable description and they are given credit. Users who have a SL greater than the lowest SL you have created, may use "/" or "\" as the first character of the description to make it a "sysop-only" file. This makes the file invisible--only the sysop or File-Op will be able to see it. Once a valid description is given. The software will check to see if the file is a ".GIF" or ".JPG" image. If it is, then the dimensions are entered into the description. Files which have a ".GIF" extension but are not really GIFs are handled properly. -60- If censoring is turned on, then only the File-Op of a file area may enter uncensored descriptions. One problem that seems to confound users is uploading multiple files (batch upload) that have different descriptions. Since if they enter the description first, all files are given that description. To make life easier on them, you might want to add the text "you will be given the chance to enter individual descriptions after the upload is completed." See also: KEYS.HLP -61- REMOVING FILES There are 3 ways to remove files: deleting them by hand, deleting them with the "oust files" routines, and deleting them by using L&D delete. The software never deletes on-line files without a human to confirm it. Deleting by hand simply involves using DOS's DEL command. It is what you probably do to delete files on your hard disk or floppies that you no longer want. When doing this to files in your downloads areas, you should do it before starting up the BBS. If you do delete a file while the BBS is running (by shelling to DOS or through a door) then the BBS will not know that you deleted it--some routines will still allow that file name to be typed, displaying a "file not found", and probably confusing your users. The software (eventually) self-correct itself when it finds the file missing (when listing File Areas). The second method, "ousting files" via the two sysop menu commands: Oust Files and Oust Files/Penalty, or by setting the "1" attribute with File Maintenance, will delete the file. The difference between Oust Files and Oust Files/Penalty is that Oust Files repeatedly loops asking you for files to simply delete. Oust Files/Penalty asks you for a file name, finds out who uploaded it, then asks you for a reason why you are deleting it (corrupt, or a duplicate, whatever), a message containing your reason and other information is sent by the AI to the user, and finally the file itself is deleted. The text of the AI's message can be found, and edited, in LINES.TXT. The third method is using the Life & Death system. When a file's L&D count is at zero ("?"), and a variety of conditions are met (see L&D menu command) then a user may choose to "reduce" the L&D value further--delete it. With any of these methods, the deleted file name, size, and description, are written out to the log file and the ALSO_GOT.LST file. If you use DOS's DEL command, then the software will recognize the files as missing and consider them deleted. If you should accidentally delete a file, and then put it back into any download directory, then the software will automatically undelete the file entry for you. If you should only change the extension of a file, the software will properly handle that as well. None of the above are as complex as they sound. I just described in detail what happens. Everything is automatic. When you use DEL you just type a file name. When you use -62- Oust Files, you just type a file name. When you use Oust Files/Penalty, you just type a file name and a reason (I like to keep mine to one word). With L&D delete you just type the file name and a Yes/No confirmation. When using the "Oust Files" command, you are able to enter wildcards. When the software detects wildcards, it does something slightly different: it sequentially goes through all the file records deleting all entries that match the wildcard. The purpose of this is to also provide the sysop a means of eliminating duplicate filenames (which are not allowed, and do cause troubles). Otherwise, without wildcards, the software merely deletes the first entry it finds that matches that name. Such as for removing FILES.BBS after installing a CD with this file in each dir (you would do an Oust Files with FILES.BB* as the file to delete). -63- MISC. When you get a percentage progress report: ▓▓▓█████ (30%) Do not worry if it ends at less than 100%, it may end at 95% if the numbers are "just so" and it may end up much lower if there are not that many things to do. If one gets "No messages found." when reading logon mail-- after having been promised mail ("You have mail in the following areas..."), then this is not a problem. It is possible the sender of the message sent it, but deleted it later (before you called) or the system deleted it because it was too old (if the Message Area maximum-messages circular buffer is in effect) and you had not called in a long while. But it usually occurs after you have already read your mail, and then went on to somehow crash the BBS or used the <alt>x command. The RESULTS file will still contain my BBS's voting totals and system statistics. Just run "update system stats" from the sysop menu to eliminate it all. The BiModem configuration files were included to aid in setup of BiModem. You still need to go through and make sure the path's and modem type are correct with BICONFIG.COM. In File Maintenance, even though the password field for a file is a number, the data entered must be a string. To change a password, merely enter the password you wish. To clear a password, merely enter a single space. -64- I AM LOST!?! If you have gotten to this point, and you have not tried the software yet, you are probably really confused. I have given you the architect's designs of the building, but all you want is the front door, elevator, and location of an office. Run the program, see what happens, how it works, etc. However, be aware that a lot does not show up until it is in full operation. In this initial configuration, it is a scaffolding--it may even appear simplistic. Do not think about what it is, or what it can be. Take change a little at a time. Look over the stuff you do not know only when you want, or need, to know it. This is not a "BBS construction set"--although it can be. You do not need to be a programmer--although you can be. YOU decide how "deep" to get into this software. Laugh off all the confusing stuff--it can be ignored, but it will be there when you need it. -65- CUSTOMIZING You probably have an urge to jump in and start changing the 101 menu ANSIs and the menu commands. Do not. Your first step should be to customize the internal structures of the BBS. This means using the sysop menu commands: Change Settings, Alter Pathnames, Toggles, and other configuration commands. Indeed, Toggles should be your first stop--as it is the easiest. Then Change Settings. These modify the limits of your BBS. Believe me, I know it is complex, I must urge you to take very small steps in your change-over of the software. Do not read more into what you see, follow the examples, if I do not say it cannot work--then you can probably do it. See also: SECURITY LEVELS, FILE AREAS, MESSAGE AREAS, CONVERSION -66- TOGGLES From the sysop or Waiting-for-caller menus you can bring up a menu of Toggles to change. Each option breaks down into a screen of Toggles. The docs for the toggles have been put on-line as part of the Toggle system. Turning off the AI toggles really does make the software much more simplistic (dumber). The AI actions were designed to continue the work the users would otherwise have to do on their own. -67- SETTINGS From the sysop or waiting-for-caller menus you can bring up a menu of Settings to change. Each option breaks down into a screen of Settings. The docs for the settings have been put on-line as part of the Settings system. Changes take effect/are saved when you exit the main settings menu. -68- PATHNAMES Selecting "Alter Pathnames" from the sysop menu brings up a menu of the pathnames the software uses internally. Each option breaks down into a screen of pathnames. The docs for the pathnames have been put on-line as part of the pathname system. This is really only for experienced users who need/want a little something special in the way their files are organized. Such as having them spread across a network. Or to better optimize multi-node operations. Be sure the pathnames you give are correct--as the software does not complain when it cannot find a pathname. And the errors you get may be subtle. But most sysop's do not have to change these pathnames. "???" expands to 3 letter node numbers (001 to 999). "***\&" expands to Style\Language codes--used to separate files by their Style and Language. The pathnames displayed on your screen will always be the "post-processed" pathnames. AFTER they had their "???"'s and "***\&" changed. But when you change it, feel free to use "???"'s or "***\&"'s if you want--they too will show up as post-processed equivalents. In other words, where I have "c:\bbs\node.???\" you will see "c:\bbs\node.001\" even though it is really stored as "c:\bbs\node.???\". When you actually edit it, then you will see the real thing. -69- MENU COMMANDS From the sysop menu, or with <ctrl>F2 from most anywhere, you can access McEditor. The Menu Command Editor. More is explained on this later. Menu Commands are 4 letter commands (eg. "PagF"--case does matter). The docs for these commands are on-line inside McEditor with the "H" command, or from most anywhere with the <ctrl>F3 command. <ctrl>F2 and <ctrl>F3 also work from the waiting-for-caller screen. -70- ANSI'S TheDraw adds blank lines to "fill out the screen" when it saves ANSIs. You should use a text editor and edit these files to get rid of those blank lines. TheDraw might also declare some ANSIs "animations" when it loads them. Ignore that. You always want to save your ANSIs as: Ansi, Clear screen, No max line length, fastest output speed. You should not use the "«", or "±", in any ANSI's before you get the callers name (all ANSI's before your "LogN" command). These characters are used to tell the other computer when to receive net mail--it may trigger a premature net mail transfer before your BBS had planned. That is, if another BBS calls your BBS looking for net mail, it is looking for these characters--since the BBS sends out these characters to tell the calling computer to begin a net mail receive. If they appear in your ANSI's, it causes trouble. Once a user logs in, then you can use the character in any of your ANSI's. Auto-detect of Zmodem or BiModem is done at all menu ANSI's. For menu ANSI's, the who's-on status line is displayed on the next line following the ANSI--so it is not recommended you have menu ANSI's that exceed 23 or so lines. Also because many communication programs use two lines to display information as well. But if you do want to use the full screen, just add a little jump code to jump up to a higher line where it can display the sysop line. If at a menu, and the user has called less than 4 times, then if they hit [Enter] three times in a row, we bring up a little helpful reminder that they should check that they have wrap-around set properly. Even if your menu ANSIs do not use wrap-around (ie, an ANSI that is one long line uses wrap- around), this is a useful little thing to tell the user that he's acting odd. Typically this appears if new users like to hold down the [Enter] key after logging in. See the "AnsQ", "ShwQ", and "EANS" menu commands for information on ANSI InfoForms and Editable-ANSIs. See also: ANSI.HLP -71- CONVERSION Some advice on converting from another BBS program: Use the Import Descriptions command to convert file descriptions. ANSIs should not be any problems, although you will have to match your menu commands with my functions. It is best to phase this in one or two commands at a time. I have a lot more commands than any other BBS program, so you will have to do some extra work to put those additional commands onto menus (although ignoring them will make things easier). If you are currently using RemoteAccess, Renegade, FeatherNet or SpitFire, then you can convert your users and messages files with CONVERT.EXE. If you are using something else, then use this program as an example, and modify it to suit your current BBS's data structures. The Convert program is entirely self-contained in standard DOS Basic. If you need help, just ask me, chances are I will do it for you. If you make changes, send me them so that others may benefit. The convert program has not undergone a lot of testing--if it does not work, tell me and I will give you a fixed version. Telegard/Renegade and RemoteAccess seem to have a lot BBS programs that use the same format (are rip-off's of these rip-off's), they may be convertible as well. For some others, it might be useful to use an intermediary conversion step (for example, WWIV to RA to JDR_BBS). -72- MODEM SETUP You must have a fossil driver installed. Such as X00 or BNU. The command line for X00 for most people is just: device = x00.sys e Your modem should be configured as such: Modem echos data (usually E1). Modem sound off (usually M0). Result codes displayed (usually Q0). Full result codes (usually X4). Verbal result codes (usually V1). Auto-answer off (usually S0=0). DTR follows connection (usually &D2). Carrier-Detect (CD/DCD) follows connection (usually &C1). DSR is properly maintained (usually &S1). So, usually ATE1M0Q0X4V1S0=0&C1&D2&S1 will do it. For your fossil speed, you should try either 19200 or 38400 and see which works best for you/your system. There is no "57600" speed for the fossil, but the modem makers like to push this number to show how fast their modems really aren't. Your best value will depend on how fast your computer is, and whether you've got multi-tasking or not, and possibly how noisy (electronic noise) your whole computer set up is. As released, the software begins with defaults of 19200 for the baud, and ATZ for the initialization string. You can change these easily at the command line (JDRBBS.EXE /?). For some commands, the computer goes into an infinite loop (locks up) when you specify a port for which you do not have a modem. Also, it may lock up if you have configured the fossil wrong (particularly if you specified a baud rate your modem cannot handle, since all your modem see's is gibberish when the fossil try's to talk to it). The following is a checklist for setting up your modem: 1. Do the X00 (or other fossil) command set up. 2. Put in your correct initialization string. 3. Change the communications port to that of your modem in Settings. For dialing, I assume ATDT, but you can change this in SHORT.TXT. Search for "dt" and "dt1-". The modem will show you what it is sending and receiving while trying to initialize the modem (and when dialing or receiving a call). If it fails to initialize, then it is -73- usually due to you setting up the fossil or your modem initialization string wrong. See also: LINES.TXT, APPENDIX J, SETTINGS, CONFIG, Q&A.DOC Example Scenario: you've just gotten a brand new Viva 14.4K/Fax. It's not configured for a BBS--it's not even properly configured for calling BBS's. The modem initialization string looks like so: AT&FM0W2&C1&D2&S1%C2S95=2 It expands to: AT&F M0 W2 &C1 &D2 &S1 %C2 S95=2 First, some background. When you get a modern modem, it is configured with "MNP5" compression ON. You don't want it on- -ZIP's don't compress any farther, and all it does is reduce speed (example: 282cps at 2400 w/o compression, 240cps at 2400 with compression ON). Also, this example modem is setup so that when you make contact you get multiple lines: CARRIER: xxxxxx (eg. CARRIER: 14400) PROTOCOL: xxxx (eg. PROTOCOL: LAPM) COMPRESSION: xxxx (eg. COMPRESSION: V.42BIS) CONNECT: xxxxx (eg. CONNECT: 19200) The CONNECT is the speed at which we told the fossil to talk to the modem. The CARRIER is the speed at which we connected with the other modem. The PROTOCOL is the type of exchange beyond mere baud rate we do (eg. MNP5). And it's all wrong. We want CONNECT to contain both the baud we connected with the other computer at, and the protocol used. Usually this takes the form "CONNECT 14400" and "CONNECT 14400/ARQ" where the "/ARQ" is used to signify the faster MNP connection. This "/ARQ" is useful in the CONNECT strings database for getting download-time estimations correct. Back to our string: AT&F M0 W2 &C1 &D2 &S1 %C2 S95=2 &F tells the modem to start fresh with the factory defaults. M0 tells the modem to keep its speaker quiet. -74- W2 tells the modem to display "CONNECT <baud>" and none of that other stuff. &C1 tells the modem to tell us about the carrier's status (DCD). &D2 allows us to use DTR on->off to hangup the phone. &S1 tells the modem to properly show us DSR status at the WFC screen. %C2 tells the modem to not do MNP5 compression. Keeping v42bis compression is OK however, it's just MNP5 compression that's bad. This changes from modem to modem, see MODEM.HLP. S95=2 tells the modem to add the "/ARQ" to the CONNECT strings if we have an MNP/etc. connection. This changes from modem to modem, see MODEM.HLP. The above can be used as a modem initialization string, but it's easier to do the following: ATM0W2&C1&D2&S1%C2S95=2&W and then use ATZ as the initialization string. This example setup string will probably work for most 14.4k modems. Learning to use the &W command (then using ATZ) is a must if your modem initialization string is too long to fit in the configuration field. If this is the case, also check your modem manual, many of the above commands are already the default. CONNECTs DB When your modem returns "CONNECT <something>" we rely on our CONNECT strings database to tell us what <something> is (and what it is to be displayed as). You can change these entries, but they should satisfy most modems. See the sysop menu for access to this database. The CONNECT strings database is divided into three fields: The actual CONNECT strings as the modem sends them, the maximum CPS rate that that connection yields, and what to show for that connection (for Last Few Callers and when downloading). When a call comes into the software, the database is scanned for a string that matches what the modem sends. If none is found, then the phone is hung up, and a "non-user" log note is made. When putting data in the "show user" fields of the CONNECT Strings database, you should endeaver to make the entry such that the first thing in the field is the actual baud rate. Example: "14400 ARQ" is OK, but "ARQ at 14400" is not. The -75- reason is that doors and some other functions use the baud rate, and expects it to be first. Throughput When displaying text/ANSIs we first blast the output to the screen, and then to the modem. This provides maximum throughput and gives the modem the best compression options. But what this means is that an ANSI could take a few seconds to display on the users end while you're looking at it on the console (if they have a 2400 baud modem for example). Modems themselves have small buffers. But you might be able to increase throughput farther by specifying a fossil buffer as well: device = x00.sys t=2048 e for example would specify a 2k output buffer. File throughput is handled by your protocol drivers, and they can vary widely. -76- TERMINAL This is invoked from the Waiting-For-Caller screen by using PROGRAM the <alt>d command. A terminal program is a program used to call out to other BBS's. The word "terminal" comes from "terminal emulator" because that's what you're doing when you call another BBS: emulating a terminal (in this case, a VT100 or VT102). From there you are presented with a screen. It has a command line, and if you just type something and hit [Enter] that something will be sent to the modem. On the other hand, if you use the arrow keys you will move into the dialer part of the screen and be able to edit and dial phone numbers. Type "?" for some on-line help. Hit <esc> to exit <alt>d and return back to the Waiting-For- Caller screen. Dialer The dialer system works a little different from normal dialers. Instead of scrolling through one long list, you are limited to the 21 lines you see. But what the software does is let you add more entries by "depth". That is, when you hit <ins> to edit an entry you can either create just a normal dialing entry, or you can create a topic entry. A topic entry is a link to another screen with 21 slots. There is no limit to how "deep" you can make entries. This system allows you to keep your most used numbers on the first screen, and put less-used (but organized) entries onto the other screens. The phone number field is to be exactly as you want to send it to the modem. For example, 1-414-643-1576. However, you can optionally specify a "+" after the phone number (eg. 643- 1576+). This "+" tells the software to go into 50 line mode when you call that number. Command Line It is a simple "do what" question. You may either choose to send a command to the modem directly, or use the "d" and "n" commands. "dt xxx-yyy-zzzz" would be to call another computer. "d xxxx" will search your Dialer entries for one containing the string "xxxx". It will then dial that number. If more than one is found, it will ask you which one to use. -77- "n xxxx" works like "d xxxx", but the "xxxx" is a net address, and the software checks its nodelists and retrieves, then dials, the phone number for that address. Note: if another BBS wants to put you through call-back verification. You should do an <alt>p just before they call you back. This will let you handle the RING, ATA, etc. without having the incoming call confused as a caller to your BBS. Misc. The internal terminal program included has a lot of features found in the better stand-alone terminal programs: IEMSI support This is a type of auto-login which is handled automatically between the BBS and the terminal program. You first define for yourself up to 3 different IEMSI identities with F5. Then for each dialer entry, you tell it which one of the 3 are to be your IEMSI identity. If the BBS supports it, you save some keystrokes and login faster. If not, nothing happens. Note: your password in the dialer entry must be the same as the BBS expects for IEMSI to work. Arrow key support The software will properly send the arrow key codes when you hit the arrow keys. Please note: this does not extend to <pgup> and <pgdn> support--which we use for Uploading and Downloading, respectively. <home> and <del> will send a <pgup> and <pgdn> code, respectively. But this is not widely supported. 50 line mode You can choose to switch to 50 line video mode. You can do this after you are already connected as well. Direct screen writing handles Internet ANSI codes If the called Internet computer doesn't recognize you, just type in "vt102" for your terminal type. We do some special handling of the ANSI codes it will send to provide a proper Internet display. -78- Smart buffer purging When you hit a key, and there are a lot of characters in the incoming buffer, we zap that buffer. No more waiting for the contents of the buffer to display before seeing the effects of your keystoke. GIP VGA graphics Like the BBS itself, when you call another BBS that supports the GIP graphics protocol, you can get VGA screens, etc. As of this writing, only other Juggernaut BBS's support this public domain graphics standard. RING detection When at the command line, and the phone rings, it will automatically exit <alt>d and accept the caller. Where this is nice is for unattended file-transfer-then-logoff sessions--that is, you do not have to wait for the file transfer to end thinking you are required to hit <esc> to exit <alt>d. Post-Upload-Processing After you hangup from another computer, if you had downloaded any files into directories defined as your File Areas, the software will automatically import them into the BBS. Both creating new entries, and doing post-upload- processing on them (getting .DIZ's, adding comments, etc.) Files downloaded into non-File Area directories are ignored. Most files have .DIZ's, so we do not bother trying to ask you to remember the description of the files. Hit <f10> when connected to another computer for help. When you have contacted another BBS, the following keys are active: <f1> toggles the trapping of all comm I/O to a file. <f2> Send a file (ASCII send--no protocols). Can use wildcards to send a random file from a bunch of files. No stop/exit key handling is done. <f9> toggle between 25 and 50 line screen modes. Note: this does clear the screen when you do it. <f10> quicky key help. <pgup> to send a file. You must enter the full path and filename of the file(s) to upload--wildcards are OK. -79- <pgdn> to receive a file. After starting the transfer just hit <pgdn>. <end> to transmit any net mail meant for that BBS. If you did not dial with "d string" or "n netaddr" then it will ask you which net address to use. Once hit, there is no way to abort <end>--since the other BBS will now accept nothing less than a mail attempt. This must, can only, be done before you enter your login name. <ins> this brings up the contents of NOTEPAD.TXT. When a string is selected, it will be sent out as if you typed it. Use a text editor to add/edit lines of text in this file. If you change your mind, <esc> will exit it--otherwise any key (such as <ins> again) will send the selected text. <alt>c this will clear the screen, and reset the screen back to 80x25 mode. Mainly useful when using GIP if for some reason you get stuck in graphics mode. <alt>h to hang up. <alt>l to "turn the tables". This allows the sysop on the other end to log into your BBS as if it were they who called you. If using JDR_BBS, then that sysop must be in <alt>p mode. If using another BBS program, then they must be in a "pure mode"-- that is, where they accept everything that comes in, and do not send ANSI codes back out (example, chat is not a "pure mode", when it changes colors depending on who is "talking".). "Pure mode" is also known as "raw mode" and "command mode". <alt>s to shell to DOS. From the shell, you may use something like LIST to examine the trapping file (if you were trapping). On some BBS's, you will be able to use <Control>S to pause, and <Control>Q to un-pause (note, you may have to hit <Control>Q twice). Unfortunately, one of the most useful abilities of most communications programs is missing: the backscroll buffer. I do plan to add this. -80- CUSTOMIZING The single key to turn the BBS "on" is to change the comm 201 port in "Change Settings", to something besides zero (like 1 for COM1:). Answer "N" to the "Null port?" question. You will need to already have the fossil installed and defined in your CONFIG.SYS. Or you can just use JDRBBS.EXE /port=1. When designing your BBS, there are three things you primarily change: the menus (commands), the ANSIs, and the text. You use McEditor to change the menu commands. Designing your own commands or just moving around what is there. This is explained farther on into the docs. You use TheDraw, or some other ANSI drawing program, to design your ANSIs. Your ANSIs are the primary "look" of a BBS. You edit LINES.TXT and TXT_BLKS.TXT to change the text that is displayed. You have complete control over all text. The words you choose provide the "feel" of a BBS. You can customize each node differently, as well as have different Styles\Languages available. Besides the ability to put any commands onto any menu, there are numerous ANSI smart-codes you can use to beef up menus (or ANSI displays) even more. For a list of these, as well as explainations of the ANSI codes themselves, see HELP\ANSI.HLP. The following files are where ALL text is hiding. Users, however, only see text from LINES.TXT and TXT_BLKS.TXT. They are all standard text files that you may edit using any text editor. IMPORTANT: When editing these files, you should completely exit the BBS (and all nodes if doing a multi-node operation) first, then edit. Do not edit them while shelling to DOS, as the index pointers will need to be updated (otherwise you will text start and stop in odd places). LINES.TXT See the LINES.TXT file itself for information on its contents. But mainly of interest to you is like 001. This contains the often-used "general logo". When the software wants to clear the screen, it sometimes uses this logo. So at the very least, what you substitute in should clear the screen. It provides a nice way to remind users what BBS they are connected to, but can be reduced to just "[0;30m[2J". -81- When you see something displayed that you want to change-- perhaps a different wording--then search for it in this file (and/or TXT_BLKS.TXT) and replace it with what you want. TXT_BLKS.TXT Blocks are lines of text that have the same first two numbers. Unlike LINES.TXT, which has its text disorganized, this file has its text organized so that all the strings for a specific routine are together. When editing the text strings, %1, %2, %3, %4 act as place- holders for data with some strings. This was done so you could more easily edit a "whole string". As this tells you how the data fits into the string, and in many cases allows you to shift the order of display around. Example: "%1 = %2, %3" If the program normally displays: "Sysop = Rohner, John" Then you could change the string to: "%1 = %3 %2" and it would display: "Sysop = John Rohner" That is, the %1's/etc. do not need to be in any kind of order. In most cases, you can also drop a %# to stop the display of the information, or add a %# to display duplicates of information: with the above changed to: "%1 = %3 the %1" it would display: "Sysop = John the Sysop" For those of you who work with C/C++, you'll notice that this is very similar to the printf/etc. command. SHORT.TXT Like LINES.TXT. It contains a hodge-podge of strings. Such as: the various censoring words, the phone dialing string, and the <ctrl>Fx hot key definitions. PRG_BLKS.TXT Is a text block file like TXT_BLKS.TXT. PRG_BLKS.TXT contains blocks only the sysop will usually see: text for the sysop commands, and system-use blocks. Almost always, this file will contain nothing the sysop cares about. SYS_BLKS.TXT Is a text block file like TXT_BLKS.TXT. -82- SYS_BLKS.TXT is similar to PRG_BLKS.TXT, but it contains stuff a sysop is slightly more likely to want to change. DB_BLKS.TXT Is a text block file like TXT_BLKS.TXT, but follows a rigid design formula. DB_BLKS.TXT contains DataBaser definition blocks. These blocks describe the various databases to use with the DataBaser system. You can add your own databases, but you should not modify those already created. The DataBaser system is described later in these docs. See COMMON\COMMON.HLP for information on how the BBS uses COMMON.LST files to determine when it should use a Language- specific version of a file, or one in the COMMON directory. LINES.TXT talks a little about its smart-codes, but these codes can be used just about anywhere. Perhaps the two most interesting ones are: @pathname@ to display a file, and &pathname& to shell and run a sub-program. The HELP dir is also filled with subdirectories filled with sample ANSIs. -83- SECURITY The software will allow you to work with Security Levels in LEVELS the range of -32,767 to +32,767. Using negative values, however, might not be recognized in some routines. There are no "locked in" Security Level values that force you define a specific value to a specific type of user. Users may have any Security Level value. You edit your Security Levels from the sysop menu command "Security Levels" under Global: Users. The software will either use their SL directly ("if SL < x then ...") or indirectly ("if SL is > x and SL is < y then ..."). This allows you to use the Security Level system as a "reward" and "punishment" system if you want. I just use a simple six level scale (5, 10, 20, 90, 95, 100) myself, but you can do what you want. Important: When entering the Security Level data in the Security Levels database, you must enter the values in increasing order (for example, 5, 50, 500--not 5, 20, 10). So that when done, your first entry contains the lowest value, and your last contains the highest. The software will make an attempt to sort any unsorted entries at the time of input. The highest (last entry) is assumed to be the Sysop level. The second highest (next to last entry) is assumed to be the Co-Sysop level. Since Co-Sysop's have a lot of the Sysop's power, you should be careful about whom you wish to give this SL out to. Even if you do not wish to have Co-Sysop's, you must still create an SL value for one. After adding/removing SL's in the SL's database, you should run "Update Stats", or you will just get nonsense when doing a "Stats Display". Do not mess around with the security levels for message area 001, Private Mail. All users need to be able to access this area, so your SL's for accessing this area should always be equal to, or lower, than your lowest defined SL. SL's (used in commands, etc.) do not have to be an SL value in your SL database. Thus, if a command requires SL 10, and you have defined SL's of 5 and 10, if you give a user 6 through 9, they still will not be able to access that SL 10 command. Ghosting Some BBS programs use "user flags" as an enhancement to their SL system. A user would have to have both the SL and the flag(s) to do a command. -84- I have a system just as powerful. It is called "SL ghosting". It is simple: you have two security levels; one that users see, and one that the program uses. When at the SL database, the real security level is referred to as the "SL value" and the security level the user see's is referred to as the "show SL". This allows you to give a user of, say, real SL 4 30 minutes per day, and one of real SL 5 60 minutes per day, while having both of them think they are level 5 because both SL's have a "show SL" of "5". But besides simple user limits, the real use for this is with menu commands. Providing a way to separate your users internally without them knowing about it. EXAMPLE ┌───────────────────────────────────────────────────────────┐ │Your BBS has the following time guidelines: │ │ │ │ Normal user: 60 minute limit per week │ │ Donated $1 : 70 minute limit per week │ │ Donated $10: 100 minute limit per week │ │ │ │Then in your SL database: │ │ │ │ Real SL Show SL Free Minutes │ │ 10 10 60 │ │ 11 10 70 │ │ 12 10 100 │ │ │ │Thus you have three different limits, three different SL's,│ │but the users never know it--they all think they are level │ │10. │ └───────────────────────────────────────────────────────────┘ -85- SYSOPS For message bases, file areas, and doors. The sysop of that area is the one true sysop in that area--the real sysop being just another user. For most other things, when I say "sysop only", what I really mean is anyone with a sysop-level security level. Pay attention to some of the commands, they offer different options and displays depending on whether the user is a sysop or not. Other stuff, like some time-out functions, work for whomever is at the console. Co-Sysop's A Co-Sysop is defined as being anyone with the SL defined just before that of the Sysop's. Example: the sysop has 100, and the co-sysop has 95. The co-sysop has many of the abilities and views of the sysop. Some of their powers: - Can delete Questionaire entries. - Can enter multiple spaces in a user name. - No inactivity time-out. - Can access any file in any file area. - Can see invisible files. - Views uncensored callers log. - Reading messages: User Maintenance Edit message info Kill file attaches Send user -> PR AI's go fish - Undelete messages - Delete File Area files - Kill Ramblings - FREQ files from other BBS's - Delete users Things the sysop can do that don't utilize pathnames on the Hard Drive. It is assumed that the Co-Sysop DOES NOT have access to the sysop menus. Any commands from those menus are likely to be the same type you would do for a File-Op/Message-Op (File Maint, etc.) and should be put into a menu for the Co-Sysop rather than letting him access the sysop menus. File-Op's A File-Op is a user whom you turn over day-to-day control of one or more File Areas to. -86- File-Op's do not have "sysop level" power. They are normal users with extended powers. Both the File-Op and the sysop always see invisible files in areas under the File-Op's control. All File-Op abilities only work in directories under their control. When using List Unvalidated files ("LUnV"), only those areas to which the user is the File-Op are listed. If the sysop is not the File-Op of an area, he too will not see (not be bothered with)its unvalidated files. When entering descriptions for files, only the File-Op can avoid description censoring. When using the following commands, the File-Op will only be allowed at files that are in areas under his control: command title menu command Oust Files RemF Oust Files/Penalty UPen Validate Files ValF File Maintenance File Normally, to support a File-Op you will have to create a File-Op menu for him to use. The above commands are a good start. This menu would normally contain at least Oust Files and File Maintenance. Also "convienence" commands such as: Add File Review, Leave a Private Message, Feedback to Sysop, List Your Area (a "PagF _#" command), etc. You will probably also have to "ghost" the File-Op a higher Security Level. If they are SL 10, give them SL 11. Then in your SL's configuration, add SL 11 but give it a "show" value of 10. That way you can make a command to let them go to their File-Op menu without other level 10 users accessing it, and you still limit this File-Op to normal (say, not level 20) commands (because everything below level 20 is not level 20). By using a "show" of 10, he doesn't know he's level 11. Or you could save yourself the ghosting hassle and just give them a higher SL. -87- FILE AREAS File Area Definitions (File Area Maintenance)--like all configuration stuff--is done in the sysop menu. EXCLUDE.LST can which can be used to stop the creation of files matching specific filenames. Useful with CD-ROM's that have multiple files (such as FILES.BBS) in each directory. Defining File Areas consist of the following fields: Download SL (minimum and maximum) Only when a user has an SL that is at least that of the minimum, and no more than that of the maximum, will they be able to download files from that area. Example: if you use 5 for min, and 10 for max: SL < 4 cannot DL SL 4 cannot DL SL 5 can DL SL 6 to 9 can DL SL 10 can DL SL 11 cannot DL SL > 11 cannot DL Normally, you just set the SL to something high, like 32000. But this "windowed access" capability lets you restrict access to users of even high SL from certain areas. Upload SL (minimum and maximum) Only when a user has an SL that is at least that of the minimum, and no more than that of the maximum, will they be able to upload files to that area. For this to matter, you must also set File Area Attribute 4 (allow uploads) ON. Scan/List SL (minimum and maximum) Only when a user has an SL that is at least that of the minimum, and no more than that of the maximum, will they be able to list (scan/view) the contents of that area. This is also the access limitor SL. So users outside this SL range cannot switch to this area. Nor will they see it listed on any internally generated selection menus. -88- These SL values are also what is used to form Master List "SL tiers". We create a Master List for each tier of access SL's (vs. normal SL's). Example: File Area 1 SL = 0 File Area 2 SL = 10 File Area 3 SL = 20 Gives us 3 SL tiers: < 10, < 20, 20+ for which we will make 3 Master Lists. When a user downloads the Master List, they are given the list appropriate for their SL. Access Time (start and end) A user may download, list, or upload files to this area only during the defined hours. Note that, starting an upload or download inside the valid time, that then extends outside the allowed time (eg. downloading a massive file) will be allowed. Set these to be the same (such as 00:00:00) to allow 24 hour (continuous) access. When outside this time, the File Area will not be accessible, and users will not be allowed to select files from that area. It will be as if the File Area did not exist. Circular buffer size. If this field contains anything other than zero, than the File Area is said to have a "circular buffer". Whenever the number of files in that area reaches this value, the oldest file will be deleted. Example: if you set it to 50: if there are 50 files in it, and someone uploads 3 files to this area, then the oldest 3 files will be deleted. So there will be 50 files again. If there were 45 files, then it would have 48 files--since it did not reach 50, there was no need to delete files. A zero value in this field means there are no limits on the number of files that can be active in this area. Oldest file being the one in the area/on the BBS the longest--not by current file date. The "never auto-delete" file Attribute will let an old file escape deletion. [note: the circular buffer is really not working] Attributes 2 means that you wish uploads and downloads to/from this area to show up in the Callers Login such a way that all users can see it. If OFF, only the sysop will see the transfer information. -89- 3 means that you wish the L&D/Point values to be shown when listing the contents of the area. Setting this OFF overrides the user's toggle to view the L&D/Point values. Whether the L&D/File Point values are visible may also depend on which Form Type you use. 4 means that users may upload to this area. When not included, any uploads attempted to this area go to area number 001 (if possible). 5 Normally files are listed in alphabetical order (A to Z). When this is ON, files will be listed in order from newest to oldest. 6 means that files in this area are said to be "transient". This is for such as floppy or CD-ROM drives--where you swap in and out disks of files frequently. When this is ON, auto-deletion of file entries not found is turned off. Example: You have two floppies, each with two files. With this OFF, each time you exchanged floppies the system would automatically delete the file entries of the files on the out floppy. With this ON, you can swap the floppies without having to redo the descriptions each time you swap in a new disk (although you do have to do them the first time, like any new file). For multiple CD's in the same drive, they must have different directory structures (defined File Areas) and by keeping both with this ON, you'll be able to rotate the disks. When this is ON, the contents of this area will not be put in any Master List either. It is only useful for BBS's which like to have a rotating file collection: "specialized CD each day of the week" type of system. Simply giving a File Area(s) an List/View min SL of 32000 might, in some cases, be better than using this Attribute. You give the SL on the "out" CD's, and change it to normal for the "in" CD. See the sysop command to globally change File Area SL values. 7 Normally the directory is sorted before displaying. Turning this ON tells you to list it as it is. This does not matter if 5 is ON. -90- Mainly useful for CD areas which have already-sorted directories. However, the ability to fold directories into each other, and to ghost files into other directories, is making this Attribute increasingly less useful. 9 means you do not wish the software to do auto- corrections of the entries in this area while displaying the contents of this area. These auto-corrections include updating/fixing file sizes, file dates, File Area information. As well as discovering new files and removing entries for missing files. For CD-ROM directories, this should be ON once you get the area and its descriptions/etc. set up the way you want it. It speeds things up, particularly on areas with lots of files. However, if you have a Primary Path defined on a hard disk, and fold in multiple CD areas, you may still want to leave this OFF so the auto-fixing is done on the hard disk area. Although, certainly, any all-CD areas should have this ON to speed things up. With large numbers of files in an area, or areas with lots of EXCLUDE.LST files, can be speeded up by keeping this Attribute OFF. But if you do turn if off, remember that the software will not auto-discover and auto-remove entries when you copy/delete files in that directory from DOS. Although the Oust Files and Move Files commands will manage the directory properly. A means to not include the contents of this area in any of the Master Lists. Master Lists are created individually for each user SL tier. Useful if you keep the descriptions in a user-downloadable list of your own (such as a ready-made list of your CD areas--speeds up building of the Master List by being able to skip some areas). B means that all files in this area are to be free. You may mix-and-match the above attributes. Maximum MB This defines the maximum number of megabytes this area may be. When it gets near this value, users will not be able to upload to this area. Beyond upload restrictions, this value is not used. -91- When uploading to this area, the "amount of free space" shown is not the real value, but rather this maximum less what is already used up. Example: if this is 100 (100 MB), and 96 MB are used, it will show "4 MB free" (unless there is less than that really, then it will show the real amount). [note: the Max MB limitor is really not working] File Form This defines which file listing format/type we should use when displaying this area. Sample formats are in the HELP\TYPES directory. The actual definitions are stored in GLOBAL\TEXT\LISTING.TXT (see the file for additional information). You may use one of the predefined types, or create your own. It is an EXTREMELY flexible system, allowing you to change everything about the headers and the way the file lines are to be displayed. NewFilesPtr This is the value of the highest NewFilesPtr that this File Area has ever seen. This is maintained internally, so you normally would not mess with it. However, it should also be reasonable (usually under 100,000). If it becomes unreasonable, just set it to 0 and it will fix itself. Sometimes a corrupt FILELIST.HDR file can mess these values up. File-Op This is a name field, and contains the name of the "overseer" of that file area. You, the sysop can do many file functions, including delete, modifying the descriptions, etc. Including a name here will allow that user to ALSO do these functions (only one name allowed). Only those with "sysop" Security Levels, or the name in this File-Op field will be able to "work on" files in this File Area. Useful for delegating the maintenance of a file area to a user. It is usually very helpful to File-Op's to create a menu containing commands they may use. Such as File Maintenance, List Unvalidated Files, Validate Files, etc. All of these have special restrictions which will only give the File-Op access to files in his controlling areas. -92- Primary Path This contains the primary path to which this file area refers. When a user uploads a file to this area, it goes in this directory. When the sysop moves a file from one File Area to another, the file is moved into this directory. Note: ghosting files to other File Areas does not move them. Title Refers to what the users see as the title when they list the contents of this File Area. Additional Paths Finally, the good stuff. These fields let you define up to 6 directories which you may "fold" into this File Area. "Fold" means that when this area is listed, it lists all the files in the Primary Path, and these additional paths. The files are also sorted into alphabetical order. To the user, it will look and act just like a single directory. We do not write or store any files to these additional paths. And they need not be only directories. For example: D:\WIN_3 will use all files in the WIN_3 dir, but D:\WIN_3\W*.ARJ can also be used to only include those files from that dir that start with "W" and have the ".ARJ" extension. Best used for folding multiple CD areas into a single area. But you can specify hard disk directories as well. Commonly used to merge CD areas with a hard drive area: Primary Path: C:\WIN Additional Path: D:\WIN_2 Additional Path: D:\WIN_3 Thus, all your Windows files are in an uploadable Windows directory, even though most of them are on the CD. Be careful though. The software is not designed to handle more than 1000 files per area, so when you are folding dirs, try to keep below this limit (think of the poor user who will page through all those files). You can use /RESCAN and /RESCANALL to do auto-fixing if you have a lot of fixing to do. Both compare what is on your -93- disks with what is defined as being on the BBS. Then it cleans things up. Only "file is on-line or not" problems. That is, if you dump a a bunch of new files into an area--it would find them and create entries. If you deleted a bunch of files, it would delete their entries. What it won't do is match the files with an area. Example: if you exit to DOS, copy a file from area #1 to area #3, doing a /RESCANALL will not fix the area. That's done when you list the area with Attribute 9 OFF. If area #3 has Attribute 9 ON, then its going to stay invisible until you turn it OFF. /RESCANALL goes a step farther and also checks the CD (Attribute 9 ON) areas that /RESCAN normally skips. Usually if your file system seems so messed up that you're banging your head--and your File Areas look fine, then doing a JDRBBS.EXE /RESCANALL will cure it. Upload-stopping works as follows: If the current area does not have Attribute 4, or the SL for the area is too high for the user, then we change to area 001. Then the same checks are made, if the user does not pass them all, then they are not allowed to upload. Some sysops like to make area 001 a hidden area, and force all uploads to it. Then at some later time the sysop looks over the files in area 001, and moves them, tests them, or whatever. Menus The software will provide you flexibility to access your File Areas with whatever method you want. These include: an internally (quick) generated menu, ANSI menu, and complete systems. Internally (quick) generated menus: These involve making use of the "_g##" and "_all" some commands have. "SelF _all", for example, will give you a menu of all File Areas you can access. "SelF _g##" will produce a menu of those File Areas you defined to be in that group (see File Area Group Handler), and to which you have access. After the menu, the "SelF" command merely switches to that file area. Other commands are "PagF" and "Upld". All work similarly with the "_all" and "_g##" by first bringing up a menu and then listing the contents of the selected area, or uploading to that area, respectively. -94- ANSI menus: This involves putting individual commands into an ANSI. Once again, the commands are: "SelF", "PagF", and "Upld". However, instead of using the "_g##" or "_all" extensions. You use these commands with no extensions (except "SelF") or with the "_#" extension (where "#" is a File Area number, eg. _1 for File Area #1). You create commands, and put the commands onto menus. Example: to list File Area #20: "Ls20" = "PagF _20". Then anywhere you put "Ls20" it will list/access File Area #20. Additional commands of use are: "PrvF" and "NxtF", for "goto previous File Area", and "goto next File Area", respectively. Complete systems: These are extended listing systems. They include "PagQ", "PagA", and "P&Sx". "PagQ" will ask you what you want to do. Selecting "All" is equivalent to a "PagA". "PagA" will cycle though all the file areas accessible using the paged method. "P&Sx" is the Point & Shoot system. A common factor to all the systems is the batch download queue. It is accessed via commands when listing the area, and automatically with the P&S system. And you can use "CntB" and "AddB" for ANSI menu options. By having this wide variety of commands, you may put File Areas any where you want. You could, for instance, shove them into a bunch, or break them up by topic--each having its own message area, menu, etc. Remember, however, that while the ANSI method provides you the maximum possible control of menu selection; the more general commands are easier to start with. The commands can be thought of as differing ways of doing the same thing. For instance, "PagQ" is one menu command, but requires two key strokes to do something. You could do the same with 4 menu commands ("PagA", "PagN", "PagF _all", and "PagS") requiring only one keystroke. Same thing, different philosophies for different sysops. -95- See also: MENU COMMANDS: File Diagrammed The file system can be thought of as being two separate File Examples parts: the first part selects a file area, the second part lists the contents of that File Area. The reason they are two parts is because once you select a File Area to list, you can move to other File Areas without having to return to that first selection menu. The file system offers a plethora of possibilities: with the menu commands, you can have the software list all areas at once, provide a menu of all the areas, use your own menu of all or some areas, provide a menu of some areas. You may put some or all your file areas into a single file system, or bust them all up so they are grouped together or individually (known as topical menus: putting a related message area(s) and related file area(s) into the same menu). All of the commands below exit back to the menu when completed. You can put a "DReq" or somesuch after them to do another command before they return to the menu. "PagQ" menu command: "PagQ" is the most powerful of all the file commands. A sort-of "all-in-one" command. Most of the other commands are made up of some fragment of this command. What this command does is first ask the user what they want to do: access all files, access files matching a search string, access all new files, or select a File Area to jump to. With access-all-files and select-File-Area, once the user is in the file system they can move to any directory. But matching and new-files does not offer such flexibility-- limiting the lists to files containing a string, and new files, respectively. "PagA" menu command: ┌────────────────┐ ┌────────┴───────┐ AREA n │ ┌────────┴───────┐EA 001 │ze desc │ │ FILE AREA 001 │ze desc │ze desc │ │ file size desc │ze desc │ │ │ file size desc │ ├────────┘3 │ Option: ├────────┘2 └────────────────┘1 Each file area is gone through. At every 18 file names or so (depends on screen size) at the end of a file area, a prompt is displayed. At this prompt the user has a wide selection of commands including commands to move to any area number. This works just like the "PagQ" access-all- files option. -96- "SelF _g##" menu command: ┌────────────────┐ │ SELECT AREA: │ │ A) area 001 │ │ B) *area 005 │ │ C) area x │ └────────────────┘1 A menu is presented containing certain File Areas (defined as a group in Group Handler). When they select an area, they are exited from this areas menu back to the calling menu--we do not list the area. Only areas to which the user has access are shown in the selection menu. "SelF" menu command: ┌────────────────┐ │ SELECT AREA: │ │ A) *area 001 │ │ B) area 002 │ │ C) area n │ └────────────────┘1 A menu is presented containing all the accessible File Areas. When they select an area, they are exited to the menu. This is just a "switch to File Area" command, not a "switch and list" command. This command is exactly what you would get using "SelF _g##" if the defined group contained all file areas. "PagF _#" menu command: ┌────────────────┐ ┌────────┴───────┐ AREA n │ ┌────────┴───────┐EA 007 │ze desc │ │ FILE AREA 006 │ze desc │ze desc │ │ file size desc │ze desc │ │ │ file size desc │ ├────────┘3 │ Option: ├────────┘2 └────────────────┘1 This command jumps to File Area "#" and starts listing files in that area. One may then choose to move to other areas. These "PagF _#" commands are good for using your own ANSI as a File Area selection screen rather than the internally created one. "PagF _g##" menu command: ┌────────────────┐ ┌────────┴───────┐EA x │ ┌────────┴───────┐EA 005 │ze desc │ │ SELECT AREA: │ze desc │ze desc │ │ A) area 001 │ze desc │ze desc │ │ B) *area 005 │ze desc ├────────┘3 │ C) area x ├────────┘2 └────────────────┘1 -97- A menu is presented containing certain File Areas (defined as a group in Group Handler). When they select an area, they are given the contents of the area. They then can move to other areas. When they exit, they are exited back to the original calling menu. Only areas to which the user has access are shown in the selection menu. "PagF _all" menu command: ┌────────────────┐ ┌────────┴───────┐EA 003 │ ┌────────┴───────┐EA 002 │ze desc │ │ SELECT AREA: │ze desc │ze desc │ │ A) area 001 │ze desc │ze desc │ │ B) *area 002 │ze desc ├────────┘3 │ C) area n ├────────┘2 └────────────────┘1 A menu is presented containing all the file areas. When they select an area, they are given the contents listing of that area, they then can move around and list other areas. When they exit, they are exited back to the calling menu (not this areas menu). Only areas to which the user has access are shown in the selection menu. This is the same as "PagQ"s select-File-Area option. This command is exactly what you would get using "PagF _g##" if the defined group contained all file areas. "P&Sx" menu command: ┌────────────────┐ ┌────────┴───────┐EA 001 │ ┌────────┴───────┐ AREA n │le file │ ┌────────┴───────┐EA 002 │le file │le file │ │ FILE AREA 001 │le file │le file │le file │ │ file file file │le file │le file ├────────┘1 │ file file file │le file ├────────┘3 │ file file file ├────────┘2 └────────────────┘1 The user has a wide selection of commands while at the P&S display. You can move both forward and backward through the File Areas. Only those file areas to which they have access do they see. There are other interesting file commands available too. Files In Area When you copy files into a File Area, these files are "outside the BBSs domain". That is, the software does not yet know about them. So, some functions, that require an active file's filename will not yet "see" the file. However, as soon as they are "seen"--when you or a user lists the files in a File Area--then they are "discovered" and given an entry, making them active. -98- When the software discovers files, the files are assumed to be complete (vs. a partial upload), and just given a blank description (shows up as "?"). CD-ROM's CD-ROM's (and other optical disks) come with lots of files and lots of variety. Some have lots of directories with few files per directory, others have a single (or a few) large directories only. Either a few very large directories or a reasonable number of medium sized directories is best. Those disks that use numbers for file names, that don't compress their files, or that put just a couple files per directory (and have hundreds of directories) I recommend you stay away from. There are two ways of accessing CD files with this software. Using a door program, or defining the CD's directories as normal file areas (as if they were on your hard disk). Uncompressed directories, hundreds of directories, or numbered filenames--then you've not much choice, use a door program (better yet, through the CD out). Otherwise I recommend defining the file areas. Since it provides the same seamless file access as normal File Areas. To avoid having all the CD-ROM files be considered "new" to new users, you can set #NEWUSER's NewFilesPtr to 1, and that of all the CD-ROM directories to 0. Also review the sections above on File Area Attributes and Additional Paths. Special Cases Normally, you provide access to your File Areas on a "the higher the SL, the more File Areas you can access" method: File Area #1 Access SL = 0 to 32000 File Area #2 Access SL = 0 to 32000 File Area #3 Access SL = 0 to 32000 File Area #4 Access SL = 10 to 32000 File Area #5 Access SL = 20 to 32000 Thus, SL 20+ can access all areas, SL's 10 to 19 can access only areas 1 to 4, and SL's less than 10 can only access areas 1 to 3. Well, that maximum SL is looking pretty useless, isn't it? And normally it is useless, because rarely do you want to deny files to people when possible. But lets give the File Areas above some descriptions: File Area #1: GIFs of cars File Area #2: GIFs of planes File Area #3: GIFs of movie stars -99- File Area #4: Tiny Toon GIFs File Area #5: Beastiality GIFs You want to make area #4 and area #5 accessible only to paid users. And you want to tailor it so users who get area #4 do not get area #5, and users who get area #5 do not get area #4. First: note that this is extremely rare in the real world, and if you are thinking about this, chances are you are thinking too hard about your File Area setup. File Area #1 Access SL = 0 to 9 File Area #2 Access SL = 0 to 9 File Area #3 Access SL = 0 to 9 File Area #4 Access SL = 10 to 19 File Area #5 Access SL = 20 to 32000 This won't do it! It gives regular users access to areas 1 to 3, and separates the area 4 and area 5 users. But what we want is to also let those area 4 and 5 users access areas 1 to 3. Note: the sysop can access all areas no matter what the security level restrictions are. In fact, no combination of SL's will let us do what we want. To get what we want, we have to change the order of the File Areas: File Area #1: Tiny Toon GIFs File Area #2: GIFs of cars File Area #3: GIFs of planes File Area #4: GIFs of movie stars File Area #5: Beastiality GIFs And set the access SL's as so: File Area #1 Access SL = 1 to 4 File Area #2 Access SL = 0 to 32000 File Area #3 Access SL = 0 to 32000 File Area #4 Access SL = 0 to 32000 File Area #5 Access SL = 6 to 32000 Thus, new users of SL 0 (or 5) can only access areas 2 to 4. But if a user pays, and wants the Tiny Toon dir, you give them SL 1 to 4 and they will be able to access that dir along with 2 to 4. If a paid user wants the Beastiality area, you give them SL 6 or higher, and they will be able to access area 5, and areas 2 to 4. -100- You didn't really need to re-order them, but it makes this example clearer. Showing that location of File Area doesn't matter, and that the SL fields of File Areas before and after do not matter. A user is allowed access to a File Area only if their SL is in that File Area's range. But more important than this example is to remember how "SL Ghosting" works--in which internally a user may have one SL, but the SL they see as theirs (the Show SL) can be something different. This is very useful, for example, when you want to give a fellow sysop higher SL, but don't want them accessing any private File Areas. Just "Show" them a higher SL, and they'll never know the difference. Ghosting files You can now "ghost files". Ghosting is showing the user one thing, when it's really something else. In this case, we show the user a file as being in one File Area, when it's really stored in another File Area. To accomplish this, merely edit the files' record so that "Show Area" contains the area to-which you wish to make the file appear. Useful, for example, for "moving" files out of one CD area and into another (such as when a Graphics dir program was wrongly placed in the Text Files dir, etc.). The file will act just like a file in that Show area. It will be displayed with that area's contents listings, it will be limited by that area's Attributes and SL's. Note: you cannot ghost files from one "non-CD" (File Area Attribute 9 OFF) area to another "non-CD" area. One or both of the areas (the real area containing the file and the ghost/sbow area) must be a "CD" area. You could, for example, put all your .GIF's into one area and ghost them by type into multiple areas (set Attribute 9 ON for either the one area, or the multiple areas, or both). -101- MESSAGE AREAS Message Area Defintions (Message Area Maintenance)--like all configuration stuff--is done in the sysop menu. Defining Message Areas consist of the following fields: Post SL This is the Minimum Security Level value a user must have to be able to leave a message in this area. Read SL This is the Minimum SL value a user must have to be able to read messages in this area. Scan SL This is the Minimum SL value a user must have to scan/list messages in this area. This is also the access limitor SL. So users with less than this SL value cannot switch to this area. Nor will they see it listed on any internally generated selection menus. Access Time (start and end) These define a time window which the Message Area may be accessible. This is rarely used. Set the start and end times to the same thing for 24 hour (continuous) access allowed. Max Messages If this value is not 0, then we delete the oldest messages in this area when the total number of messages in this area reaches this value. Example: set this to 500, then once we reach 500, each time a new message is added, the oldest message in the area is deleted. Thus keeping the total number of messages in this area at 500. Very useful for popular Echos. You can protect messages from deletion by setting their "don't auto-delete" Attribute. Set this to 0 to disable automatic deleting. Next Number This is an internally used field, and is unlikely to be modified by you. -102- It contains the number to give the next message posted in this area. If you see that the number is really screwed up (8 digits for example) then you should fix it to something reasonable. Attributes 1 means that the FROM: field should be forced to "Anonymous" for all messages posted in this area. Nobody (but the sender) will know who left the message. 2 means that this is a Private area. The messages are only visible to the sender, receiver, or Message-Op. When OFF, the area is Public, and the messages are visible to all. When using the various message reading menu commands, pay attention to which read private mail, and which read public mail. They do not necessarily read each other's type. 3 means that the area should be inspected when receiving or sending Net Mail packets. It is also necessary if you wish to enter a node address when entering mail, and seeing the node addresses when reading mail. If an area does not have this Attribute, then no Net Mail will be put there, and no messages will be sent out from there. Also, this Attribute tells the software to add special "^A" "kludge" lines to the message. You can really have only two areas with only Attribute 3 ON (and not with Attribute 9 ON): private NetMail, and public NetMail. With private NetMail, any private Net Mail that does not have a matching EchoMail message area will be put here. Similarly for public NetMail. If you have only one NetMail area, then both private and public NetMail goes there. No net areas? Then inbound NetMail (and no-area EchoMail) will be put into the Private Mail area. 5 means that only the Message-Op can delete any messages in the area. This stops both the poster and receiver from deleting the message. Useful for areas which provide information that others might be interested in. 6 means that all messages are forced to use "ALL" as their "TO:" field. This includes replies. Nobody is allowed to enter a name in the "TO:" field. -103- 7 means that NetMail "kludge" lines are shown (these lines begin with an ASCII 1--a little happy face). This also toggles the showing of EchoMail lines: ---, * ORIGIN:, SEEN-BY, and AREA:. The Message-Op can hit "S" when reading messages to toggle this ON and OFF on-the-fly. 8 means to automatically delete NetMail messages in this area after they are [Sent]. Obviously, this also requires Attribute 3 to be ON. Normally this should be ON for your NetMail areas (but not EchoMail). 9 means the area is an EchoMail area. Attribute 3 must also be set to ON for any EchoMail area. Thus, when this Attribute is ON, so must be Attribute 3. A means we should append the BBS's own Origin lines to outbound EchoMail messages from your BBS. The Origin line is usually just wasteful garbage, and if you want to attach one, see SHORT.TXT. B means to use the author's real name for the FROM: field. This is used to "force" real names--some EchoMail areas demand it. C means to NOT include the sender's name in the quoted brackets. Example: ┌(John Rohner) ┐ becomes: ┌ ┐ │text │ │text │ └ ┘ └ ┘ D means to report the active status of the sender and receiver names. If the name is not in the current users list, they have a little "(not a current user)" noted beside their name. This is particularly useful for Private Mail. E means to allow anything in the At: field. Normally long-form addresses like for Internet. We do not really use this now, but it will be in the future. You may mix-and-match the above attributes. Message-Op The Message-Op is the sysop of the Message Area. Any messages posted TO:SYSOP in this area will get that persons name. -104- Beyond that, there isn't much special about a Message-Op. They can look at any message, delete any message, etc. But a lot of their power relies on what the sysop gives them. Some nice things the sysop can give them is the ability lock/unlock access to one or all users to the message area. See the "Lock", "LsLk", and "UnLk" menu commands. The sysop could outfit a Message-Op menu with related commands, maybe a related file area, etc. Title The title of a Message Area is what is displayed when scanning the area, reading messages in the area, and for internally generated select-area menus. You are free to modify any areas as you wish, except for area #1. This is always Private Mail. The Message-Op is always the sysop. Menus The Message Area commands are quite similar to the File Area commands. For instance, "SelM" to select a Message Area is just like its "SelF" (select File Area) brother. Most of the other commands, for reading and writing messages, are less generalized and usually only offer the non-parameter form (uses the current area) and the "_#" parameter form (switch to area "#" first and then do the command). Toggling When a user toggles a message area INACTIVE, it is quite similar to making the area out of their SL range. All menu commands that build menus of Message Areas to switch to will not display those that are disabled. The next/previous area commands will similarly jump over these areas. Only 3 things work: the Message Area toggle menu will show them, login mail read will allow the user to read messages in these areas, and the "SelM _#" command also works (eg. "SelM _3"). This list of can-do stuff is the same for SL- restricted message areas. This "disappearing" is done because that is assumed to be the way the user wanted it when they chose to toggle inactive the areas. Out of sight, and out of mind. -105- PSEUDO-AI The Pseudo-AI can only send private messages (E-Mail) in and out of the Private Mail base, number 001. Any messages redirected from the AI to the sysop go to the sysop. All software generated messages (such as AI's "Hello", or Return Receipts) have their "kill when received" Attribute ON. This means that when the message is read, it will automatically be deleted. That is, the AI automatically cleans up after itself (a lot of users don't delete their mail). But the messages the AI sends are every bit real and normal. Beyond messages, however, the Pseudo-AI is the "smarts" in the program. When a user doesn't have to do something that he normally would do, the AI is said to have done it for him. -106- MINUTES There are 3 types of time maintenance minutes. There are Access Minutes, Download Minutes, and uploading. Uploading is easy to understand: no time is reduced from anywhere during uploading, and they may even get Download Minutes if you have auto-crediting for the uploads ON. Download minutes are just that: minutes a user is allowed to spend time downloading. This is reset each day to the values specified for their security level. This value is also used to determine the maximum amount of time a user may spend in a door per day. For that reason, they may be referred to as Download/Door minutes. Access Minutes are everything else: putzing about on the BBS, reading messages, etc. The kind of thing you usually want to give users a lot of. There are per-call and per-day values for this. Uploading/downloading and dooring do not count against these values. With high speed modems, download minutes don't really matter, and tend to act as merely door-access-limiting minutes. Download/Door minutes get used up when downloading or in doors. But first the "free" minutes you give them each day is used, then when they have exceeded those we start subtracting (permanently) any "given" minute credits they had. When a user's minute-credits reach or exceed 32,767, it will never increase. When it reaches -32,767 it will not be reduced farther. Crediting of download minutes for uploads is defined in the protocol definitions, and in Settings: Extended File Crediting (for those who like exotic crediting schemes). -107- GROUPS There are lots of groups with this software. Groups are good. The is grouping by security level. You know all about this. Another is groups of users based on their name. You do this in the sysop menu option: Users: Group Handler. With these groups, you are able to restrict access to both files and menu commands (the "ifGP"/"ifnG" commands). The last user grouping is Linkages, and is the least used. Linkages allow multiple users to maintain common file transfer statistics. So that when one uploads, the other guy can make use of those credits for downloading. This is done in the sysop menu option: Linkages, and is otherwise invisible. It takes effect when downloading--as the users statistics will appear different than if he were not linked with another user. A single name can be put into a group. This allows you to do such things as limit a file, or whole command operations, to a single person. The IndividualANSIs system is particularly for single-user stuff as well. The other types of groups are groups of Message Areas, File Areas, and Doors. These work like the user Group Handler system, and have their own group management commands. -108- VOTING The voting questions are contained in the VOTE.TXT. This file is structured as follows: Number: total number of questions Text: line 1 ┐ Text: to line n: question text │ a Number: total number of options (x) │ single Text: line 1 │ question Text: to line x: options text ┘ Text: line 1 ┐ Text: to line n: question text │ a Number: total number of options (x) │ single Text: line 1 │ question Text: to line x: options text ┘ Text: line 1 ┐ Text: to line n: question text │ ... etc. Or to simplify: n <- Total number of questions. Text Q1 Line1 <- Question 1, can be up to 14 lines. Text Q1 Line2 3 <- Number of options for question 1. Option1 <- Each option. Can have up to 7. Option2 Option3 Text Q2 Line1 <- Question 3, can be up to 14 lines. Text Q2 Line2 4 <- Number of options for question 3. Option1 <- Each option. Can have up to 7. Option2 Option3 Option4 Text Q3 Line1 <- Question 3 on, same as before. etc. Example: 2 <-number of questions. Do you like furry animals? <-question #1 3 <-number of options. Yes <-option 1/3 No <-option 2/3 Yes when they are in a zoo. <-option 3/3 Do you like the great outdoors? <-question #2 4 <-number of options. Yes, I visit them a lot. <-option 1/4 Yes, I have a garden. <-option 2/4 Yes, I have a plant at the office. <-option 3/4 No, burn it down. <-option 4/4 -109- You may only have a maximum of 7 of your own options for a user to select from. But the software also provides an "No Opinion" and "Other" (the default) options for each question. Giving you up to 9 possible answers. The "No Opinion" option is the same as not voting--and will result in the question repeatedly coming up (next call) if the voting is is being done at login (mandatory/forced voting). "No Opinion" is not considered a real vote, and so is not graphed. When a user chooses "other" (the final voting question option), they are prompted to enter text describing what they mean. This can sometimes be a simple option you neglected to include, or a whole complex belief idea. this text is then sent to the sysop as a message from the AI. You may then use their answer to decide if the voting options need more options. When an option's text runs into the graph, you will need to shorten the option's text. The graph shows all options except "No Opinion". The graph automatically re-size's itself between 50% and 100%--to maximize graphic variability. Deleting a voting question is a bit tricky. You cannot simply delete a question unless it is the very last one. This is because if you did simply delete it, all the others would move up one--and all the user records (where the results are stored) would have results for the wrong question. So when you want to delete a question, you should first come up with a question to replace it with (and change VOTING.TXT with this new question). Then go to the sysop menu and select "Reset Voting Question", and then "Update Stats" ("Update Stats" will reset that voting question's totals to zero). -110- DOORS A door program is any program you temporarily pass control too. The key word is "control". Simply shelling and running programs like DSZ.EXE or PKZIP.EXE is not dooring to those programs. Defining Use "Door Maintenance" from the sysop menu to maintain doors. This is a defining database, it has nothing to do with the menu commands. It creates "door objects" which the door menu commands can use to actually execute doors. The whole door system works very similarly to the File Area and Message Area systems. The menu commands work are quite alike. Doors consist of the following fields: Access Time (start and end) Access to this door is allowed between, and including, the times supplied here. If the two values are equal, then access to the door is allowed during all 24 hours. When using the "DOOR" and "DOOR _g##" commands, if the door is inaccessible at that time, it is not included on the menus. Maximum time allowed in door The maximum number of minutes a user is allowed in the door per door access. The door handles this, so it is by no means guaranteed. Use some high number (like 999) for unlimited access time. If the user's "download minutes" is less than this amount, then their "download minutes" amount is used instead. That is why they are called Download/Door minutes. A zero value will still execute the door (it is always the door's responsibility to guard the time) but if it is handled properly by the door program, they will not be able to use the door program. You'll learn quickly to hate doors that have no time- limiting code. Logging type 0 = none 9 = everything the door program has 1 to 8 are somewhere in between (door program defines, you should look at the door program's documentation to see if it supports this capability). -111- Minimum drive space needed The minimum drive space (in bytes) that the door needs on the drive to run. Usually this will be very small. If you want to use 0, you should be sure the door program updates no files (including the door-exit files). 2048 will be fine for most doors, but some may need a lot more if they need to update large data files (example, a daily packing would need at least a megabyte--probably 2 or 3). So it varies widely, which is why this field is here--the door program will not be run if there is not at least this amount of drive space. Door-Op Who is to be the door-sysop for this door. Only this name will get sysop treatment from the door program. Path Drive\path specification of the door program. Example: C:\BBS\DOORS\BRE or C:\BBS\DOORS\BRE\ or E:\ etc. It should contain the path of the door programs' files. Where the door is on your hard disk. This field is the drive that is checked to determine that there is enough space. If empty, no space checking is done. This field is almost never empty. Execution Filename and command line to execute the door. If your door program is at C:\BBS\DOORS\ABC.EXE you would put C:\BBS\DOORS\ above and ABC.EXE here. Command lines are of the form: ABC.EXE %N %D\ABC.CFG /a /k Where you are mixing the doors' "%" commands with whatever command line commands the door program wants. The following "%" codes are expanded when found in the execution line: %P Comm port (1..n) being used. %N Node (1..n) being used. %B Baud rate (2400, 4800, 9600, 14400, 19200, 38400) of user (actually it's of your computer<->modem connection, but it is what door programs want). -112- %D Path to current door's directory (what you specified in Path above). No trailing slash is added. %T Max minutes (1..n) allowed in door. %W User's name (spaces converted to "_"). %X User's name (spaces kept intact). Example: ABC.EXE /NODE=%N /CFG=ABC.CFG Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1" (if comm port = 1 of course). That is, no leading or trailing spaces are added when substituting for these codes. Most doors will accept a filename in the command line to mean a file in the current directory (the directory in which the door program resides). So it is rare that you will ever need %D or any path in the command line. These codes are the same as used by protocol execution lines. The door program will decide which ones you will need to use. Title The title is displayed for any internally generated selection menus. Exit Info Attributes These are used to tell the software what type of door exit file the door wants, and whether we should do a full exit from the BBS or not. The vast majority of door programs assume a BBS is just a dumb front end. And they go into great detail about batch files to run their programs, and configuration setups, etc. Ignore it all! Never, ever, give a door program any path other than that of its own directory (eg. BBS\DOORS\ABC). The only exception to this rule to maybe give it the location of your Callers Log so it can log some sysop info for you (rare). This software is smart. It not only exits itself into that door programs directory, but also puts the door-exit file(s) in that directory as well. The directory we do this with is whatever you put in the Path field above. The following are the Door Exit Attributes: 1 This produces a DORINFOx.DEF door-exit file. Also known as "RBBS" type door-exit file. Almost all your doors -113- will use this. Only the older door programs may need something else. 2 This produces a DOOR.SYS door-exit file. Also known as "Gap" type door-exit file. 3 This produces a CHAIN.TXT door-exit file. Also known as "WWIV" type door-exit file. 4 This produces a SFDOORS.DAT door-exit file. Also known as "SpitFire" type door-exit file. 5 This produces a PCBOARD.SYS door-exit file. Also known as "PC-Board 14.x" type file. 6 This produces a PCBOARD.SYS door-exit file. Also known as "PC-Board 12.x" type file. 7 This produces a CALLINFO.BBS door-exit file. Also known as "WildCat! 2.x" type file. A Normally we shell-to-dos to run a door program. However, if this Attribute is ON, we do a full exit. Taking the entire BBS out of memory and giving it to the door program to use. If, when testing a door program, you get "Cannot execute filename", then this error means that there was not enough available RAM to run the program. You should then set this Attribute ON. You should always at least try a door program without this Attribute--the size of the .EXE is not a good indicator as to how much memory a program uses. Most programs will give the quick "cannot execute" error, but some will work fine, and then get buggy after using it for a while--so you should set this Attribute ON for them as well. See SHROOM.HLP for a swap-to-disk/shrink method you can also use. Normally you just set one of 1-7 ON. Technical note: The software will not read back in the above door-exit files. However, it always writes out its own (JDRBBS##.DEF) and will read that back in--adjust the users record for any changes. See TECHDOCS.DOC and DOORS.DOC. Access Security Level (minimum and maximum) If the user has a Security Level less than the minimum, or greater than the maximum, specified values here, they will not be able to run the door program. -114- For "DOOR", and "DOOR _g##", these inaccessible areas simply are not displayed. For "DOOR _#" commands, the door is not executed. Menus To call a door program from a menu, you use the "DOOR" menu command. This command has 3 formats: DOOR, DOOR _g##, and DOOR _#. "DOOR" is the easiest to use. It simply brings up an internal menu of all accessible doors. The user selects a door program, we execute it, then we return to the original menu. Doors to which the user has no SL are not listed. "DOOR _g##" is similar to just "DOOR". But instead of all doors, we use a pre-created group of doors. See Doors: Group Handler in the sysop menu for more information. The menu created is an internally generated one, and doors that the users does not have the proper SL to access are not listed. Both of the above are pretty easy, and should be used while you are getting your doors organized and set up. Once that is done, many sysops like to design their own door-access menus. For that, we have the "DOOR _#" command. Where "#" is the door entry number (from Door Maintenance) that we should execute. To use these commands, you first create one or more menu commands using "DOOR _#". For example: "dor1" = "DOOR _1" "dor2" = "DOOR _30" "dor3" = "DOOR _5" You then create an ANSI menu with the new commands ("dor1", "dor2", "dor3") or put one or more of these commands onto an already existing menu. Note: the "DOOR" menu command above is NOT the same thing as the very similar "Door" menu command. "Door" is a quicky shell-to-dos-and-run-something, and does not create door exit files nor track time/usage stats. See DOORMENU.ZIP for information on implementing the pull- down door-access menus I use on Immortality. These are very tricky, and you should have mastered the menu system before thinking about implementing it. Time Like file transfers, time spent in doors is reduced from the Maintenance users' daily download minutes available. A user may call a door as many times as they want. You may set a "maximum time" a user may spend in a door per session, -115- but since a user may use the door any number of times, ultimately they are limited by their total time available. Before calling the door, the software will verify that they have time available. Technical note: A door program gives minute-credits, or removes them, for reward or loss, respectively. If a door program you are installing has the ability to define the rate of exchange (example: 1 minute-credit = $100,000) then set this value such that the highest a user would ever attain (in total) does not exceed 32,000 and the lowest they ever attain (in total) is not below -32,000. Minute-credits should not casually be played around with in the doors, they should represent seriously high goals in the game. A gambling door, for example, should not use 1:1 minute-credit ratios, but rather the byte part of the exchange rate ($1,000,000 or $10,000.00). Currently I know of no program that makes use of this. See also: MINUTES Misc. I have been testing some of the door programs with this software, see the file DOORS.DOC for helpful information on setting up various door programs. To speed up the loading of doors, use PKLite or a similar utility on the .EXE and .COMs. However, if you get the message "has overlays, continue?" then answer "No"--these programs, like JDRBBS.EXE itself, have internal overlays that cannot be accessed if they are compressed. When a door is run as an event, no time checking/handling is done. Since there is no user. If you set something up wrong, the good door programs will tell you what was wrong. Setting up a single DAILY.BAT file which contains all the door-related events to run at midnight is a lot easier then setting up different commands for each event. Using "Door" to call these maintenance programs (or this DAILY.BAT) is also a lot easier than using "DOOR" for the same thing. -116- PROTOCOLS You can change (add/remove/modify) protocols from the Protocols option on the sysop menus. Some protocols, such as xmodem, you cannot use to upload-- because they stop and ask you (the sysop/console) for a filename to use. For bidirectional protocols, you must use the "BiMd" and "HSLk" menu commands to get BiModem and HS/Link, respectively. This is necessary because otherwise the software will only look for either downloads or uploads-- these commands tell it to look for both. However, their definitions (command lines, etc.) are still defined like any other protocol. Defining When we make references to the "log entry" below, we mean the log the protocol itself produces to tell us what happened. Protocols have the following fields: Defining letter This is the letter the user sees for "protocol" in their Profile. If you use two letters that are the same, you should be sure that their SL ranges do not conflict. The very first protocol is known as the default protocol, it is given when the user's selected protocol (somehow) has no allowable match. You may reassign the default protocol by using a defining letter of "*". Access Security Level (minimum and maximum) The minimum and maximum Security Levels provide a range in which the user must be to be able to use this protocol. If they are less than the minimum, or greater than the maximum, specified then they will not be able to use the protocol. For the "Select Protocol" command, it will not display protocols to which the user does not have SL access. You can temporarily disable protocols by setting their minimum value to something very high, like 32000. It is easier to just disable a protocol then delete it, and decide later on that you want it back. Using a min SL and a max SL allows you to direct different flavors of the same protocol to different users. Example, in my set up, level 5 users do not get to do Zmodem resume- later upload aborts, and so I use a DSZ line that does not save incomplete files for that Security Level. -117- Example, DSZ uploading: "pR1" means "delete incomplete files," and "-r" (eg. "-mrS") means "allow them to complete their partial uploads. These you should definitely use for lower-SL users, and allow for higher SL users. Because lower SL users will cause troubles by uploading duplicate files--and the protocol will overwrite your old ones without these extra parameters! But at the same time, one assumes the smarter higher-SL users know what they're doing (and that they can lose their higher-SL by doing this file- replace trick). That they can be trusted that what they upload is important and should not be hassled by having to resend the whole thing when it only needs to be completed. If the Maximum SL value is zero, then it is ignored. Allowing any SL once the minimum SL requirement is satisfied. Success UL letter This is the letter, when found in the log file, that declares that the upload was successful. Fail UL letter(s) These are the letters, when found in the log file, that declare the upload a failure. See Fail DL letter(s) as well. Success DL letter This is the letter, when found in the log file, that declares that the download was successful. Fail DL letter(s) These are the letters, when found in the log file, that declare the download a failure. Users do not loose any download minutes or download bytes when a download fails. We then they continue-later the aborted download then their records are adjusted properly. However, if you're having trouble with abusive users downloading 90% of GIFs, then aborting, one trick to stopping these people is to remove the "E" from the DSZ protocols for Fail DL Letters, and put it into Success DL Letter. Thus, aborted downloads will also have credit reduced. However, this should not be done lightly, as regular users who really do have a problem with a download will not like it costing them double-download credits. -118- The solution I like to use is to wait until they log off (or if I notice lots of E's for DSZ transfer lines in the log) and then simply add those bytes to that users Bytes Downloaded. Thus, when he next logons, he see's that the aborting trick did not work. Technical note: The following is fairly detailed, and you may not ever need it (recommend you read it only if you are having troubles detecting bad uploads). In order for the to correctly identify bad transfers, either this field must be one character, or the pass/fail determining word must be one character. Example: DSZ's pass/fail word is either "E" or "L"--one character. So you can have up to 3 characters here ("LE"). If some other protocol has "Bad" for failed transfers and "Good" for successful transfers, then you must put a "B" or "a" here, not "Bad", not "Ba", not more than one character because the pass/fail determining word is more than one character. To simplify: the software looks for the "Fail letters" inside the "pass/fail determining word" and looks for the "pass/fail determining word" inside the "Fail Letters". If either of these cases come up true, then the transfer is determined to have failed. This allows me to find: "L" or "E"--rather than trying to find "LE" in the pass/fail word. So, while "LE" will not be found in "E", "E" will be found in "LE". If you have "LE" and the protocol leaves multiple letters, such as "Lbad", then it will not find the "L"--since either "LE" will not be found in "Lbad" and "Lbad" will not be found in "LE". Pass/fail determining word This is the "word number" of the letter that determines whether the transfer was successful or not. The word number of the log entry. Words are defined as text having a least one space between them. Example: "A B C" has 3 words, but "A BC" has only two. If the protocol produces entries that are some times blank (rather than, say, a zero), then you cannot use it (unless the trouble occurs after the determining and pathname words). Pathname word-number This is the "word number" of the transferred pathname in the log file. -119- The pathname need not contain a full file path. It should at least contain the file name transferred. Percentage of time to give This is the percentage of upload time (as determined from 2400 baud) that you should give in minute-credits. No time is taken off for uploading, except with bidirectional protocols. This credit is given them in the form of Minute-Credits and is done at the time the file is validated or whatever other rules about credit-giving you have. Only minutes are given (back), not bytes. Bytes for upload credits is always the same: simply adding the size of the file to the user's uploaded-bytes total. The amount this eventually converts into depends solely on their ratios for their Security Level at the time of consideration (ie. when downloading). Description This is the text the user sees when selecting and using the protocol. Log File Pathname This is the full path and file name of the file in which the protocol keeps the log of what happens. Upload Execution This is the execution line we should use to handle uploads to the BBS. In both execution lines, you should include the full pathname of the protocol driver being used. Example, "C:\BBS\DSZ.EXE". The following "%" codes are expanded when found in the upload/download execution lines: %P Comm port (1..n) being used. %L Transfer pathnames file to use (usually FNAMES.CTL). %B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of user. %N Node (1..n) being used. %U Path to currently selected File Area. %F For first filename (of a download session). -120- Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1" (if comm port = 1 of course). That is, no leading or trailing spaces are added when substituting for these codes. Download Execution This is the execution line we should use to handle downloads from the BBS. See Upload Execution above for the "%" codes allowed. For batch download protocols, you must use protocols that accept the "@<listfile>" command line order. This "<listfile>" is FNAMES.CTL which contain a list of pathnames to send. Typically, the command line will have a "@%L" to tell it what files to download. For non-batch download protocols, you must use the "%F". This takes the first entry in FNAMES.CTL and replaces the %F with it. Allowing you to send that one filename. Protocols which can handle the sending of only one filename are not recommended. The program is set up to use "DSZ.EXE" for its protocol driver. To change this to a different protocol driver, such as GSZ, you have two methods: easy and hard. The easy way is to just rename it to DSZ (this only works if the command line parameters follow those of DSZ (which GSZ does), and you do not need to use DSZ in another protocol). The hard way is to go into Protocols and change each DSZ entry by hand, and then go into Executable Lines and change those DSZ.EXE entries. Renaming GSZ to DSZ.EXE works just fine. I have not tested the other protocol driver programs (such as SZMODEM, etc.) for this simple renaming trick, but it probably will work. Although some, like IceZmodem, have a non-DSZ compatible command line, and so either need their own Protocols entry, or for you to modify your current DSZ command lines. -121- MENU SYSTEM Ah, the menu system. The key to JDR_BBS. It's sneaky, may even appear hard at first. But it is very, very, powerful. It will be a long time before you master it completely, but you will be able to master much of it quickly. This is the KEY! Understand this, and you will understand the whole software package. Everything makes sense when you master this, the whole thing becomes a thing of beauty. Don't fight it, it is really not that tough. Definition What is a menu? In the "good ole days" a menu was something the program itself took care of. The programmer(s) decided how it was to look and which commands were to be put on it. More recently, this system has evolved to where we use an "image" (such as an ANSI) for the menu display. However, many programs still limited the commands that you could have on which menus. Now, we are in an age of much more powerful menu systems. Where the actual display the user see's is of minor importance. All the work is done behind the scenes: the sysop configures for hot-keys to use, Security Levels to block/allow commands and images, commands that go to sub- programs, scripts/command builders, and all sorts of combinations. This flexibility allows sysops to change software without having to change too much of the look and feel of their BBS. In this software, menus are: zero or more images grouped with zero or more commands. Menu's are referenced by a three character ID, known as the Menu ID. Typically, a menu will be a single ANSI with 3 or more commands on it. There are three parts to a menu: the image to display for it, the commands to use in it, and the commands themselves. Please re-read this. Commands are like objects--they do nothing until put them on menus. In this software, the "commands to use on a menu" are not equivalent to the "commands themselves". They can be, and most often are, but need not necessarily be, because they are built up from other commands. As you shall see later, the Menu Command system is separate from the Menu system. Most everything with this software deals with objects. You have databases full of object definitions. Commands make use of these database objects, but are themselves objects. The menus make use of these command objects. Each step defines -122- the direction and power the original object is molded into. We take data objects and route them, mold them, and shape them, until they are in a form we deem acceptable for callers. The ANSI's and other forms of images (RIP, GIP) you build outside the BBS software, using something like TheDraw. Once you know what you are doing, you will find text editors, such as PC-Write, to be helpful as well to create, edit, and optimize your ANSI's. McEditor For this software, creating your menu's involve using the Menu Command Editor System, or McEditor. The following files are used by McEditor: CMDS.DAT --Contains all usable commands. CATEGORY.DAT --Contains information about which usable command is in which category. FX.TXT --Special effects for menu's when a selection is made. BBS_CMDS.DAT --Contains commands used in each menu. MENUS.DAT --Contains each menu. FX.TXT is the only file you can edit yourself. It contains the special effects strings that you can display after a caller selects a command from your menus. It is a standard text file. See HELP\FX_TXT.DOC for more information. The remaining files McEditor handles. CMDS.DAT and CATEGORY.DAT store the functional information about how each command works. These files are stored in BBS\GLOBAL\SYSTEM. The bottom half of the McEditor screen is for editing this information. BBS_CMDS.DAT and MENUS.DAT store the information for the menus. The top half of the McEditor screen is for editing this information. These files are stored in the Style directory to which the menus apply, for example "1ST". You can access McEditor in two ways: from the sysop menu, or just hitting <ctrl>F2 nearly anywhere. Designing menus can sometimes get tricky--you literally design yourself into a hole sometimes. For instance, you make a change that stops your access to the sysop menu. That is why the <ctrl>F2 key is there. -123- The McEditor screen looks something like so: Menu ID: xxx ANSI: x:\xxxxxx\etc. ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘ ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘ Category: xxxxx ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘ ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘ There is not that much to remember. What you see are actually two separate systems: the top half of the screen is the menu system, and the bottom half of the screen is the command system. The whole system is an "object oriented drag-and-drop menu command block-building system". You can type "?" to get the commands, but they are pretty straight forward: arrow keys to move, <ins> to create/edit, <del> to delete, <enter> to pick up and drop down objects, <pgup> to move to previous category or menu, <pgdn> to move to next category or menu. <esc> to quit. "H" will bring up the on-line docs for the menu commands. You can also use <ctrl>F3 from most anywhere to bring up these docs. Use <left> and <right> to move into the Menu ID and Category fields, <up> and <down> skip past them. The "?" brings up help (and used hot-keys) when used on a blank object. When used on a non-blank object, it reports on the contents of that object. An object being a menu entry, or a category command (those boxes in the picture above). To make the commands a bit more readable, "?" will bring up a "human readable" form of the command as well. The "/" key can be used to toggle ON/OFF continuous reporting. When ON, every object you move the cursor across will have its contents displayed--and the "?" will display help alone. When OFF, "?" for help only works on blank objects. When <ins> is used while at the Menu ID field, or the Category field, you are able to do a variety of things. It lets you type something, and then will ask you what you want -124- to do. [Enter] alone will abort any operation. Things you can do include creating new menus/categories, jumping to a menu/category, duplicating, swapping, etc. You can move individual command objects around: simply move over what you want to move, hit [Enter] to pick it up, then move where you want to drop it, and hit [Enter] again. You can use this to move commands between categories, to move menu commands between menus, and to move commands from categories to menus. It is easier than <ins> which requires that you type in a cmd4 name. "@" at the menu commands is useful as well. Just do an "@" on top of a menu command, and it will locate for you which category has that commands definition. You can use "E" to export menus or categories. And "I" to import menus or categories previously exported (example: a friend gives you a menu or menu system (Style\Language)). When importing, it puts the new stuff at the front of what you currently have (menus or categories). When exporting, only menus can be saved multiple per file. The type of import (menu or category) is automatically detected, but to export, you hit "E" on the menu or category you wish to export. It is easiest to just play around with it for awhile. Just remember that the bottom half defines commands, and the top half uses those defined commands. Menus Menus are made up of the following: a Menu ID, a menu ANSI, and the menu's commands. Each "page" for the top half of McEditor is for a different menu. You can create as many of these menus as you want, and put whatever commands you want on them. The software is in no way locked down to the menus I have or the ANSI's I use. These "pages" provide an interface between your commands and the user: in these "pages" we tell the software what the user sees (the ANSI), we tell the software what the user can type (the hot-keys), and we tell the software what its supposed to do when a key is selected (the commands). But it's still up to you, the sysop, to draw the ANSI's (with TheDraw or somesuch) and define the commands. While I always say ANSI here, you can use .RIP and .GIP screen images in place of the ANSI image. The menu ANSI can do all the smart-codes. See ANSI.HLP. -125- While the ANSI is being displayed, and after it is displayed, the software will accept any valid hot-keys for the menu commands. The hot-keys available depends on the users and the hot-keys' Min SL and Max SL. You can quickly turn a menu command ON/OFF by a Y/N for the active field. The command itself must be a valid category command, or a ">xxx" jump-to-menu command (which need not first be defined in the bottom half of McEditor). The hot-key can be any keyboard character. Including numbers, and characters like "!@#$%?':,." The following are special. They work as themselves, but also tell the software to accept special keys: hot-key what to accept ~ [Enter] < <left arrow> > <right arrow> ^ <up arrow> _ <down arrow> If no "~" is defined as a hot-key, [Enter] normally just redraws the screen (unless pull-down/arrow menus are used, then it is used to select an option). Minimum SL and Maximum SL. The user must have the minimum SL to execute the command. They must also be less than or equal to the maximum SL to execute the command. If Maximum SL is zero, then only the minimum SL is used for consideration. By using upper and lower boundary SL's, we are able to define multiple commands that use the same hot-key--they could be designed to work differently for different SL ranges. This is quite useful, and easier than separate menus. Special effects is text displayed after the user hits the hot-key and before the menu command itself is executed. The special effects themselves (what is shown etc.) is specified in the file FX.TXT. You can use "L" to switch between menu systems. For example, to edit the "WW4" menu system, you would type "L" then the path to the "WW4" dir: c:\bbs\node001\ww4. McEditor defaults to whichever menu system you are currently logged in under. See DOORMENU.ZIP for a complex example about how to implement pull-down menus. When using pull-down menus, -/+ also works to move between commands, and [Enter] selects. Even though -126- they are called pull-down menus, they can be of any form-- they are just menus that user can move about the screen using the arrow keys. See also: ANSI.HLP, STYLES\LANGUAGES Command First and foremost, all commands are four letters. But they Objects may have parameters of variable size. There are three types of commands: "|###", ">xxx", and everything else. "|###" are system-level notation--you should never use this, all functional commands are built upon these notational (core) commands. These are known as "primitives". ">xxx" is a "jump to menu xxx" where "xxx" is a Menu ID. This command changes the program flow to another menu. The first action upon going to a new menu is to display that menu's ANSI. Any other 4 letter command is a constructed command. Created by using the above commands, and parameters for the above commands. Parameters for any command always has a leading "_" before it. Example: "PagF _1", "PagF" is the command, "_1" is the parameter. The "|###", ">xxx", and any created 4 letter commands are referred to as "objects". When editing a command, there are 78 characters available for you to define the "functionality" of the command. The functionality of a command is built up using other commands and parameters. You can have a remark using the "'" (apostrophe) character--anything on the line following that character is ignored. The key to understanding commands is that each 4 letter command represents an object, whose functionality is defined by the commands that make up that object. That is, like painting, you create new colors from color primitives. Here, you create new commands from command primitives. Well, I hope I haven't lost you. It makes a bit more sense after you play around with McEditor for a while. You will find that most "regular" commands are a single command. The ability to build new commands is something for special situations and to provide further customization. Example, there is a command to display an ANSI, "dANS". Which is nice, but the ANSI displays and before the user gets more -127- than a glance at it, we're back at the menu. So we look around a bit, and see the "ENTR" command--which waits for a user to hit a key. We put them together to have the software do what we want: display an ANSI and then wait for the user to hit a key. Which looks just like: "dANS _pathname ENTR" (quite useful for display top scores files from door games). Each command/object can be stacked/linked/joined/etc. just like toy blocks. Think of each 4 letter command (and its related parameters) as a toy block and the system is easier to understand. The key is that this is a block construction language, in which you take blocks and mix-and-match them. block types: ┌────┐ ┌─────────┐ ┌───────┐ ┌────┐ │cmds│ │pathnames│ │numbers│ │etc.│ └────┘ └─────────┘ └───────┘ └────┘ you then take these, and form larger commands: ┌──────────────────┐ │┌────┐ ┌─────────┐│ ││cmds│ │pathnames││ │└────┘ └─────────┘│ └──────────────────┘ ┌────────────────┐ │┌────┐ ┌───────┐│ ││cmds│ │numbers││ │└────┘ └───────┘│ └────────────────┘ ┌──────────────────┐ │┌────┐┌────┐┌────┐│ ││cmds││cmds││cmds││ │└────┘└────┘└────┘│ └──────────────────┘ and bigger: ┌──────────────────────────────────────────────────────┐ │┌──────────────────┐┌──────────────────┐┌────────────┐│ ││┌────┐┌────┐┌────┐││┌────┐ ┌─────────┐││┌────┐┌────┐││ │││cmds││cmds││cmds││││cmds│ │pathnames││││cmds││etc.│││ ││└────┘└────┘└────┘││└────┘ └─────────┘││└────┘└────┘││ │└──────────────────┘└──────────────────┘└────────────┘│ └──────────────────────────────────────────────────────┘ Thus, you choose the reading difficulty: one big command, many small commands, or something in between. The software does not care. -128- All the 4 letter commands that exist are "built" upon "|###" commands. 4 letters is a lot more readable then "|###", which is why they are there--to make the commands created more readable. I could have had it use more than 4 letter commands instead of requiring creating 4 letter commands--but it actually makes things more complicated. Think of the 4 letter commands as little icons. I would like to emphasize that while it may sound like a programming language, it is in fact not. There are no complex loops, or variables, or any such stuff. Just the placement of one needed command next to another to produce a new command. Commands The easiest way to work with all these commands is to just take what you need--don't try to create a BBS that uses everything. Just because there is a phone call-back command, for example, does not mean a call-back system is something you would like. There is a wide variety of commands to appeal to the different needs of different BBS types. Because of the way the menu system is implemented, you can change any of these names if you don't like them. Implicit to all the commands is that they will return to the current menu when completed. The most "combinations" a command can have is: Cmd4 Cmd4 _### Cmd4 _g## Cmd4 _all These break down as such: "Cmd4" -- work with the current whatever. "Cmd4 _#" -- work with # whatever. "Cmd4 _g##" -- show a menu of all whatever's in group ##, and then do whichever whatever is selected. "Cmd4 _all" -- show a menu of all whatever's, and then do whichever whatever is selected. That is to say, the commands follow a common "expansion" system. Where you first work with the current, then a specified individual, then a selected group, then all. Only a few commands use all four possible expansions. Hit "H" in McEditor for a full list of available commands. Misc. From any menu, the software automatically checks for a Zmodem or BiModem upload. Users can upload by "just doing it" from any menu, and the software will detect it and act accordingly -129- (jumps into the protocol, no searching done, not done if not enough space). When listing hot-keys used in the "?"s help--the dark grey keys have been toggled inactive. No matter what we do with menus--loading, moving about, switching between menu systems, etc. The categories are always the same, and common to them all. As well as common to all Styles. -130- WAITING FOR The Waiting-For-Caller (WFC) screen contains 6 "objects" of CALLER SCREEN information: drive space, Callers Log, status indicators, the bottom line, and (with toggles) memory information and caller statistics. There are a bunch of Settings you can change for this "WFC Desktop". Including the size and colors for the Callers Log viewport. We'll begin with the easiest: the bottom line. This line contains the time and day of week. When a call comes in, it displays "[RING]" when the phone rings (if using an X00 compatible fossil driver), and displays (quickly) whatever the modem sends to us. The drive space section, upper left corner of the screen, shows the available space on drives you have deemed important enough to show this. The callers log, upper right of the screen, shows the last few callers' log entries. You may scroll this using the arrow keys. The lower-left corner has status indicators. In the brown box is the number of messages waiting for the sysop, and the number of new files since the sysop's last calls. The Faxes section isn't working yet. Below this, first, are 3 modem indicators: "CTS" which is usually down, "DSR" which is usually up, and "DCD" which is usually up. When there is an incoming call, first "DSR" goes down (phone taken off hook) and then "DCD" goes down (carrier detected). Although, depending how your modem is configured, "DSR" may do nothing, and is not really needed. Moving a little to the right we have "Trap". When this is down, that means we are trapping everything to SESSION.LOG. Beneath these are two chat indicators. "Chat" is down when we are trapping chat sessions to the trap file. The two little faces are down (connected) when the sysop is available for chat. Hitting <F8> brings up a daily statistics summary, which you can scroll through as well (+/-). There is a debugging Toggle that will show you a little memory available information. Here are some more hot-keys from the WFC screen: F1 brings up a hot-key help screen. F9 normal console login (with reading of new mail). -131- F10 brings up a menu of various stuff to do. <end> turbo console login (no mail reading). <alt>d goes to the internal terminal program which you can use to call other BBSs. <alt>s shell to DOS. <alt>z exit to DOS, but take phone off-hook first (callers will get a busy signal). <alt>x exit to DOS, leave phone on-hook (callers will get continuous ringing--normally you do not want this). F2 toggles on/off whether we should automatically trap chat sessions. F3 toggles on/off your available-to-chat status. F6 toggles on/off screen blanking. When on, the screen will stay blank until you do another F6. Note: console beep's are also disabled. F8 toggles on/off the display of the daily stats. <pgdn> toggles on/off Trap All <alt>h hot-list-limitor, see below. <alt>p port-debugger. This is a command line access to your modem like all terminal programs offer. It is useful for such things and verifying that your modem initialization string works, and looking at the modems NRAM settings. <ctrl>Fx will do whatever you define. Usually it will take a couple of seconds until connection speed is determined. However, it could last the full "logo" time-out time if the connection was one you had not specified in your CONNECT strings database (for instance, this occurs with 300 baud callers). This is because, for baud rates you do not want, the system merely waits for that caller to hang up, or for them to time-out. Entries are recorded in the Callers Log for these "bad connects". They are of the form: "Non user called at <time>. Connect: |...|". The "|...|" is the crucial information. It will tell you the exact string the software received from your modem. A bad connection may contain just garbage, a 1200 connection would look like "| 1200<garbage>|" usually (if you deleted the 1200 entry from the CONNECT strings database). If you forgot any CONNECT strings, this will tell you the information you need. Note, however, this line is also given for connects for net mail and when a user simply hangs up without entering their name. Hitting <alt>H accesses the Hot-List-Limitor. This allows you set a list of user names who are the only ones to be allowed onto the BBS for a specified period of time. After that person calls, their name is removed from the list. After the specified time, or when the list is empty, normal -132- callers will again be allowed to log in. To have a name on the list be able to call more than once, specify their name in the list more than once. Hitting F10 brings up a menu with: Alter Settings --change Settings. Crash Contact --FREQ/Net FA/Exchange Net Mail now. File Maintenance --edit file entries. Post A Message --leave a message in any area. Remove A File --oust an on-line file. Toggles --change Toggles. User Maintenance --edit user entries. View A File --display a text file. (exits when RING detected) The same "Post A Message" command we have at WFC can be used in a shuttle login menu. This command asks for a FROM: name, and if that name is that of a current-user, it asks them to first login. After all, can't have random callers leaving people messages using other peoples names. However, this limitation is removed when used from the WFC menu. There is a Toggle that will let you lock the keyboard from doing <alt>/etc. commands. When on, all anyone can do at the console from the WFC screen is <F9> to login locally. See also: SETTINGS, TOGGLES -133- THE "WHO'S ON" Below each menu ANSI, the console will show a user status STATUS LINE line. It looks something like this: User Name--Location 5sl 10calls 2msgs ctn Which breaks down as: "User Name" is just that, the callers name. "Location" is the callers city and state. If flashing, then this is the text they typed for a chat request. "5sl" is the callers show Security Level value ("5"). "10calls" is the number of times the caller has called. "2msgs" is the number of messages the caller has ever posted ("2"). "c" appears if chat trap-to-file is on. "t" appears if trap all to file is on. "n" appears if sysop-on-next is on. "PR" appears if the user is undergoing Peer Review. A music symbol appears when you are allowing users to try to chat with you. Users do not see this information line. When you logon at the console, you will also not see it. Most communications programs use a locked-down last screen line or two. Which I am sure worked great in the old days, and with BBS's that need user command lines, but for this software it just messed up the presentation too much. Both because we can use that 25th line for ANSI's, but also because we use that line for lots of other useful stuff as well. -134- ACCOUNT VALUE Accounts do have value. The harder they are to get, the more value they have. Simple higher SL values increase their value. Adding Peer Review increases the value of all passed accounts. Adding other requirements, such as name verification (users send in proof of their name) or phone verification (call back testing), further adds value. Finally, stats are seen by all--so if a user has a lot of UL credits, that account has worth. What does this mean? It means you could have troubles as accounts increase in value. More hacking attempts. Users selling, or trading accounts. Probably other stuff I have not thought of. Another problem, however, is "worthless" accounts having value. Example: if you give new users free download bytes. Suddenly its easier for some users to log in as new each time rather than upload. You can give old accounts value by setting up "UL credit each time the file is downloaded" system. Even as part of your regular system, set it up so that 1% is given again to the uploader whenever that file is downloaded. This will encourage users to stick with their old accounts, and to upload popular files. -135- EVENTS All events are done after a user logs off, or after the "WFC inactivity" time has passed when no user in on-line. Example: a 00:00:00 event does not occur at 00:00:00. But at 00:00:01 if no user is on. If a user is on it will be executed after they log off. There is no forcing a user off for events, or reducing their time for an event. If you REALLY need to execute an event at a precise time, you can create an earlier event (say 15 minutes earlier) to do a "-Usr" which will stop callers. At this time, however, I am aware of no events that require they be executed at a specific--and only that specific--time. You could also use Security Level-based access start/end times to limit users out of a time frame. This would be useful, for example, if you run a real busy BBS and need to poll for mail each night--but need to poll multiple times because that BBS also is busy. Access start/end times are like events. These exist for Security Levels, and for doors. Unlike normal events, however, these do have a functional limit: the start and end time must not cross 00:00:00 (midnight). Examples: 1 am to 11 pm is fine, but 9 pm to 3am will not work. The software works using a 24 hour clock, so the start/end times you define must outline a "time bubble" within this 24 hour clock. Although I have not confirmed it, I think the events will not work properly if an event is a full-exit door. I suspect it will just keep looping running this event. So do not do full-exit doors for events (if you need to door, use shelling/shrinking "DOOR"s, or the "Door" command). To stop the execution of events after restarting the BBS, you can use the /NOEVENTS command line parameter. See also: MINUTES Defining You set up events on the sysop menus. Events contain the following fields: Execute it after This is the time we should do the event. Ideally. In fact, this time will be used if a user is not on-line. If a user is on-line, we do the event when they log off. -136- But not if after This provides us with an execution window for the event. If for some reason we have passed this time, we will not do the event. This is useful, for example, to stop net mail polling of a Hub. You would poll for an hour, then stop. The command line command /NOEVENTS is useful for stopping events after your system crashes, but using this time limitor is a also a good method. Set this to the same as the event start time to have no maximum time limit of execution. Days of the week Which day or days of the week to execute the command on. M = Monday R = Thursday N = Sunday T = Tuesday F = Friday W = Wednesday S = Saturday Remember that events that occur after midnight actually occur on the next day. Example, if you want to have an event execute in the middle of Sunday night at 3:00am, you would set the event to execute on Monday--since 3:00am Sunday night is actually Monday morning. Menu Command This is the actual event to do. It is a 4 letter menu command. While there are many pre-made events you can do. Most of the events will need to be created. For example: "NODd _phone _zone" to poll a net address, or "Door _pathname" to run a door maintenance utility. Attributes 1 When ON, we take the phone off-hook before doing the event, and put it back on-hook when the event is over. If you have an event that is going to take a few minutes, you want to do this so callers do not just get continuous ringing while the event is executing. 2 Disable the event. When ON, the event is inactive and will not do anything. -137- 3 Retry every 5 minutes. This is only for the call-out commands (net mail commands). If the command did not establish contact with another BBS, then it is reset and will be tried again in 5 minutes. This only works from the current time to the top of the hour (example: start it at 2:01am, when it gets to 2:59am we give up). If we did establish contact, the event is considered successful and completed. Node This is the node to execute the event on. Usually your less-used node. You should not configure two or more nodes to poll the same Zone at the same time. Example: you want to poll 1:100/1 and 1:200/1. You can either set these up as two events on one node, or in two different "time boxes" on two nodes. But do not, for example, poll 1:100/1 on node 1 from 1am-3am and poll 1:200/2 on node 2 from 2am-3am. Because in the off chance of both getting connections at the same time, they would both use Zone 1's directory (MSGSTUFF\1) and could get confused. For different networks (different Zones) there is no combination that causes trouble. Only when the Zones are the same, and you are doing it at the same time on multiple nodes. Description A description to help remind you what the event is. -138- OH OH! From now on the docs deal with the very complex topics. Stuff that may confuse you even after running the software for a few months. Now is a good time to stop reading docs and play more with the software. -139- STYLES\ These are tricky, watch yourself. LANGUAGES Let's begin with some terms. A "menu system" is a group of menus stored apart in their own files. They are distinct from other menu systems. The images (such as menu ANSIs are not really part of the menu system). A "Style" is one of these menu systems combined with menu images. A Style has one menu system, but may have many Languages. A "Language" is a group of menu images. Also known as a menu set, or theme. It can be just a couple menu ANSIs, or more complex complete-text replacements. Thus, we have following: ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │Style 1 │ │Style 2 │ │Style 3 │ │ │ │ │ │ │ │┌─────────────┐│ │┌─────────────┐│ │┌─────────────┐│ ││Menu System 1││ ││Menu System 2││ ││Menu System 3││ │└─────────────┘│ │└─────────────┘│ │└─────────────┘│ │┌─────────────┐│ │┌─────────────┐│ │┌─────────────┐│ ││Language 1-1 ││ ││Language 2-1 ││ ││Language 3-1 ││ ││Language 1-2 ││ ││Language 2-2 ││ ││Language 3-2 ││ ││ . . . ││ ││ . . . ││ ││ . . . ││ ││Language 1-n ││ ││Language 2-n ││ ││Language 3-n ││ │└─────────────┘│ │└─────────────┘│ │└─────────────┘│ │ │ │ │ │ │ └───────────────┘ └───────────────┘ └───────────────┘ I opted not to use "Style X" for the name of Styles. But instead choose to use 3 character identifiers. Thus, "Style 1" became "1ST", "Style 2" became "RED", and so on. The sample shuttle/matrix logon system can be activated by just doing: JDRBBS /1stcmd=SHUT (to turn it off, do JDRBBS /1stcmd=STRT). The "SHUT" menu command is stored with the 1ST Style, so for the above to work, your "Default Style\Language" Setting will need to be "1ST\1" (the sample shuttle ANSIs are in with the 1\ Language). If you want to do this with the other Style\Languages as a default, you must duplicate the "sht" -140- menu from 1ST into that new Style, and copy the appropriate files (SHUTTLE.ANS, FX.TXT) into that Style\Language directory. Technical note: After a user hangs up, we load the Default Style\Language. After we know who the user is when the login, we load their Style\Language. So it is most efficient if the Style\Language most of your users prefer is the same one you have configured as the default. Directories Thus, the files for "Style 1" are stored in 1ST\, and the files for "Style 2" in RED\, etc. Or more specifically, d:\BBS\NODE???\1ST\, etc. Each Style can only have one menu system, and these are stored in that Style directory (1ST\, RED\, etc.). Languages are also stored in that directory, but in their own subdirectories. So "Style 1, Language 1-1" is stored in "1ST\1\", "Style 1, Language 1-2" in "1ST\2\", and "Style 2, Language 1" in "RED\1\", etc. If you look at NODE001\, you will see the Styles\Languages: 1ST\1 \2 \3 \4 \5 \6 \7 \8 \9 \A RED\1 \2 WW4\1 JDR\1 Four Styles, various numbers of Languages depending on which Style. It is a very flexible system. You can add new Styles or Languages whenever you want. You can easily exchange Styles (normally) or Languages (less so) with other sysops. Just ask that sysop for a copy of their Style, plug it in, select that Style (New Languages user menu) and your system will both look and feel EXACTLY like the BBS that gave that style to you. Above is the easy stuff. To really customize your own Style\Language you have to learn to master McEditor, and get a better understanding of how individual files are used and stored in Languages (the COMMON system). But first, a little more on directories: The two important notations are "???" which converts to node, and "***\&" which converts to Style\Language. Any pathname may contain these, and they will be converted. For one node, it really does not matter if you use "???" or "001". -141- But with two nodes? Well, as it turns out, it only matters if the second node is to be different from the first. So, initially, we create our second node by copying all of NODE001 to a NODE002 directory. This allows us to completely, and uniquely, customize node 2. For example, if node 2 is a sysop-only node, you can delete from the NODE002 directory all the Styles\Languages you yourself do not actually use. However, if your node 2 is to be exactly like node 1 (and these examples apply to nodes 3 to 999 as well), then you delete most of NODE002 completely. ─┬─NODE001─┬─1ST ─┬─NODE001─┬─1ST │ ├─RED │ ├─RED │ └─TEMP to: │ └─TEMP └─NODE002─┬─1ST └─NODE002───TEMP ├─RED └─TEMP When the nodes are two be identical, you should take the time and go into Alter Pathnames and change all "???" to "001". This will lock those pathnames to the NODE001 directory. The only one you should not do this for are the NODE???\TEMP\ entries. Then just keep your NODE002\TEMP directory and delete all the other directories and files in NODE002. This trick only saves about 500k (depending on how many Styles\Languages you have set up), and for the most part is not worth the extra work. However, if you have more than two identical nodes, or just don't like trying to keep all the menu systems in sync, then this may be a good thing. Alter Pathnames tells the software where the files are, so you can place them wherever you want. You can also make files that are not currently node-specific, into node-specific by using "???" in their pathname (example: to make the Style\Languages node individual, change the pathname to d:\BBS\GLOBAL\SYSTEM\LANGS.???). When you do this, you will have to login into each node separately to change the files from the sysop menu (example: log in node 1 to change LANGS.001, node 2 to change LANGS.002). If you have many nodes, and they just have a couple different styles, what you can do is drop the "???" node identifiers from the Style and Language files, and pull the Styles completely out of the NODE??? directories: -142- ─┬─NODE001─┬─1ST ─┬─NODE001───TEMP │ ├─RED ├─NODE002───TEMP │ └─TEMP to: ├─1ST └─NODE002─┬─1ST ├─RED ├─WW4 └─WW4 └─TEMP It requires a little trial and error, and a bit of work in both Alter Pathnames and the menu systems themselves (changing the location of the ANSIs for example). Really, this stuff should only be considered by those with 3 or more nodes. You see, because the Style\Languages contain nothing but text to read, they do not need to be part of each node directory. The trick to remember when doing this stuff is to keep the TEMP directories inside the NODE??? directories. Heck, you say, why didn't I do this for the release? The answer is because all those Style\Language directories would clutter up the \BBS directory. By keeping them inside NODE001, they are nice and organized. It doesn't matter where the Style\Language directories are, just that you have their pathnames right. There is nothing that says you have to offer the same Style\Languages on each node. The power of this system allows each node to produce a BBS look and feel totally different from each other. Styles A Style is 3 files and and a Language directory. Those 3 files are: MENUS.DAT, BBS_CMDS.DAT, and COMMON.LST. MENUS.DAT and BBS_CMDS.DAT are used by McEditor. They are the menu system for this Style. COMMON.LST tells the software which text/image files are to be gotten from the Language subdirectories, and which from the BBS\COMMON directory. The BBS\COMMON directory holds files that are "common" to more than one Language. That is, files that are identical between Languages. Rather than wasting drive space storing a duplicate of each file in a Language directory, we put them in this COMMON directory. COMMON.LST tells the software where the files are. -143- See BBS\COMMON\COMMON.HLP for more information. Some pathnames in various menu commands use "_COMMON##"--these are referencing this COMMON.LST file for the pathname information. Languages In the Language subdirectories, you usually find menu image files (ANSIs), LINES.TXT, TXT_BLKS.TXT, HELPBLKS.TXT, and some others including .IDX files. Really, any file that that Language may need could be stored here. Or, as pointed out above, it is a fairly standard file, it may instead be stored in the COMMON directory. If you want to modify a file in the COMMON directory to make it more unique to a Language; first copy it into the Language directory, then modify it. Then modify that Style's COMMON.LST file so it knows to use the copy of the file in the Language directory. The COMMON directory can be thought of as a baseline directory--where the software goes when it can't find the file in the Language directory. We save space by not putting it into the Language directory if there is already an exact copy of it in the COMMON directory. Your own style What's involved in making your own style? Not much, just change what's already there. Or creating a new 3 letter directory, and copying, for example, 1ST\ and 1ST\1 into it. Merely creating a new directory is not enough, you must provide a way to change to that directory. That is why the sysop's menu "Styles\Languages" command exists--to allow you to define alternate views of your BBS for your users. Then just edit the ANSIs and text files to your liking. Same with that Style's menu system. Add more Languages, etc. Get additional files from the COMMON dir, or maybe just change those files outright (would affect multiple Languages). Use the "L" command in McEditor to load and work on menu systems. Just type "L", then the path to the Style (eg. "c:\bbs\node001\1st" that you wish to play with. Each menu system can have menus with Menu ID's that are the same as in other menu systems. The reason this is OK is because the ">xxx" goto-menu command does not look outside the current menu system for its menus. Menu Commands The "LngS" menu command provides the user a list of all defined Styles\Languages and allows them to select one. -144- When using this command, all Styles need to have a Menu ID that matches the Menu ID of the menu which has this command. So that, for example, when we switch to RED\2 from 1ST\1 we stay at the User Stuff menu. Example: we do "LngS" from Menu ID 004 in the RED Style, we select the 1ST\1 Style\Language (only the Style matters), we change to that Style's menu system, and locate its Menu ID 004 and display that. If that Style had no Menu ID 004, we would not know where to go. However, you can put a ">xxx" command immediately after the "LngS" to tell it which Menu ID to go to (for example: LngS >001 will switch to the main menu of the newly selected Style\Language, rather than try to stay at the same Menu ID). When you switch to a different Style\Language, the software reloads all its menus and resets all its pathnames to adjust for any needed pathname changes. As an aside, there is a User Attribute which allows you, the sysop, to stop users from being able to change their Style\Language. There is also a menu command, "LANG", which can be used to change a users Style\Language preference. This alternative allows you to make your own "change Style\Language" menu rather than having the software generate a menu of all possible Style\Languages. Finally, there is THE command. "MENU _path". I have been very nicely pointing out how a Style contains a single menu system. But the hard reality is that each Style is a menu system. And that Languages are not necessary. Both the Sysop menus and the DOORMENU system are menu systems. This command switches between menu systems. When you've mastered McEditor, and bounce around the Styles\Languages, and understand DOORMENU, and peeked and were not impressed by the sysop menus, then you are ready to understand this information. Until then, skip to the next section. It is this command that is ultimately executed when you change Styles. The "LngS" and "LANG" commands hide this fact from you, but they to are really just aspects of this "MENU" command. What the "MENU" command itself allows YOU to do is organize your menu systems. Unlike the Style\Language-specific commands above, this command does not change the Node and Style stuff. It instead merely loads a whole new menu system. -145- These whole new menu systems can be one menu to a thousand menus. But since its purpose is to organize your menus, usually its a group of menus that share a common theme. The sysop menu system is just such an example. I COULD mix all the "user" menus with the sysop menus--but as anyone who saw .08 can tell you, that's REALLY confusing. So I toss them off into their own directory. There is only one key to remember about actually using menu systems. That key is that you must change to them before you can use them, and you must change back when you are done. Typically, you switch to a menu system with a ">xxx" so it goes to and displays a menu. That is: "MENU _path >xxx". Everything that has previously been referred to as "menu systems" is a lie. The fact is that all the menu systems together form one giant menu system. When you shift between "menu systems" you are merely shifting to other branches of this huge menu system tree. Styles are "exclusionary" branches. That is, you can only be on one at a time (for any one node). But any other menu systems, like the sysop menu system, are not exclusionary, and are merely "GOSUB'ed" to. We do not deal with such hassles like node numbers, Styles, or Language fields. It's a simple "all the files for this menu branch are in this path, go use them". Some notes: when the user hangs up in a menu system everything is reset to normal, and you cannot do a full-exit door in a menu system (but you can when the menu system is a Style\Language). This is the Zen Master command of the menu system for Juggernaut. When you are able to create groupings of menus just because you want the organization, and are able to properly call and return from them, you will have achieved complete understanding of THE menu system. In the meantime Grasshopper, study the sysop menu system to see how it does things. But beware the Black Night known as DOORMENU, for it is rumored to be even more complex. -146- TEXT FILE The Text File Management System allows the sysop a method to MANAGEMENT organize text files. It is both a G-Files and Bulletins SYSTEM system. It is quite flexible, and based on the "TXTF" menu command. "TXTF _#", where "#" is 1 to 999. It stores the text files in an archive (TXTF_###.ZIP). For example, "TXTF _1" uses "TXTF_001.ZIP". It uses an access interface exactly like <alt>d. See also: TXTF, TERMINAL PROGRAM -147- DIRECTRY'S Directry's are collections of information stuck into one file. Also, notice it's spelled "Directry" not "Directory". There are three files for each directry: DIRECTRY.D##, DIRECTRY.T##, and DIRECTRY.I## (which the software creates and maintains). DIRECTRY.D## contains the information (the Data). This file has the format: HEADER/NOHEADER %%% text line 1 . . . text line n %%% text line 1 etc. The first line contains whether the screen should be cleared and the logo (LINES.TXT line 001) displayed (HEADER/NOHEADER). The second line is our first "separator line" and consists of "%%%". From then on we alternate between information and "%%%" lines. DIRECTRY.T## files contain the Titles, and are of the form: First line: Line of text that makes up the heading. 2nd line : Text of the question to ask. n lines : n lines of titles for each information element in the DIRECTRY.D## file. The size of the longest title determines how many titles are put on each line for the selection menu. Using a max title width of 20 will get you 3 entries per line. ## corresponds to a value of 01 to 99. Directry files need not be in sequential order: 5, 19, 37, 88 or 1, 2, 3, 4 are OK. See the menu command "DirV" for information on setting it up in a menu. When called, the list of titles will be displayed, a selection made, and the information corresponding to that selection/title will be shown. The whole system is designed for you to create whatever DIRECTRY's you want--up to 99 of them. I have included three samples: Unprotects, ANSI's, and Music Quotes. -148- Use HEADER if you want the BBS logo header line to be displayed above each data item. Use NOHEADER if you do not want anything displayed above the data item (usually implies the data item will handle it). Anything else besides HEADER or NOHEADER will be displayed above the data item. You can use LINES.TXT codes in the data text. Just use a text editor to create/modify the .T## and .D## files, then just restart the BBS--the .I## files are built/updated automatically. It is a very nice and powerful system once you realize how simple it is. But it is not quite as automatic/efficient as the Text File Management System. But it can handle everything from single line quotes to full screen ANSIs. See also: DirV, LINES.TXT -149- USER VOTING This software supports two types of user voting: a message- based Peer Review system, and an InfoForm-based sysop review system. Peer Review Peer Review is a restriction system--to restrict users. To turn it ON for all new users, set Attribute "0" to ON for #NEWUSER (you will need to do this again if you ever re- initialize #NEWUSER). To turn it ON for a single user, set "0" to ON in that user's record with "User Maintenance". When reading mail, when you, the sysop, hit "*", the message is sent to a review file, and the user is tagged as undergoing Peer Review. Should you hit "*" for another message from a user undergoing Peer Review, then this message is also added to their review file. When users of a defined Security Level value range log on, they may vote on these review files. To lessen the hassle to those users in the range, they are only given one to do per logon. Those already voted on are skipped, and users may not change their vote. If the user hang's up while in the voting mode, their vote is cast as "Don't Care" for that review. At each logon, a user undergoing Peer Review will be given the tally so far and offered a chance to see what the voters see. When the number of positive or negative votes exceeds a value you specify, then that user is said to have passed or failed Peer Review. They will be given whatever SL value you specified. A message will also be sent to them telling them they passed or failed. When a user passes or fails, that fact is recorded in the log for all to see--so those who care about how the voting went can find out. The complete review file is moved into DEL_MSGS.TXT. This system can be useful for limiting beginner users. It is also useful for accounting. If you double-bytes-off a user, and they go below their ability to download, this process discourages "jumping to another account" and encourages one to repair their account rather than abandon it. When a user is undergoing Peer Review: during the login process, if they do not have any mail waiting, they are offered a chance to see what the voters see. See also: SETTINGS -150- Sysop Unfortunately, this software does not yet support the popular InfoForms "User fills out InfoForms, other users vote looking at those filled out InfoForms". Maybe next version. What it does have is something similar: user fills out InfoForms, and sysop decides whether to let user have higher access. It works pretty simply: you have new users (or those applying for higher access) fill out one or more Questionaires. Then you use the view questionaire command to look through them, deleting them, etc. When a user fills it out to your desires, you later give him higher SL manually. This system is not as troublesome as it sounds. And you get the most important part right: the user fills out InfoForms. It's just the "voting" system which is different from normal (and this is invisible to the user anyways). The InfoForm method is nice because you get to use some rather nice looking ANSI questionaires. However, the Peer Review system lets you get more in-depth detail about a user, as well as a long sample of their writing (the message(s)) which is a very good indicator of maturity. See also: MENU COMMANDS -151- DATABASER The DataBaser system is a sysop-designed data base system. All DataBaser databases rely on DB_BLKS.TXT to define a database, and the "DBEd" or "DBVw" menu commands to access the database. This makes the whole system (mostly) free from any hardwired code. If you decide to take the time to understand this system, you will be able to create custom databases which users can access, as well as being able to create database definitions which can be used to access data files from other programs. Just one thing to remember: do not modify the stuctures of any databases I have pre-created. They all have very specific coding inside the software to use certain data structures. When you List the contents of a database, you can start the listing from any record by merely typing in the record number instead of the "L" for List at the command line. Many of the ready-made databases also offer up "!" which let you access records using a scrollable window. DB_BLKS.TXT Each DataBaser definition has a format along the following DataBaser lines: Structure Line 1: Descriptive text about the database. Appears ... when the "DBEd" menu command is called. Line n: <end> Line n+1: database's file name. Line n+2: database's definition specs. Line n+3: Question line to use when modifying. Line n+4: The object name of the record type (subject of the database). Line n+5: Heading output text. Appears at top of listing. ... Line n: <end> Line n+1: Body output specs. ... Line n: <end> Line n+1: Field to use for the windowed selector. Line n+2 to end: text describing each field. Example: 50Fuzzy Bear's data base of warez. 50 50<end> 50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT 50S12S40U 50record number : 50warez 50 -------- Fuzzy'z Warez Data Baze --------> -152- 50 Rec ==File Name== ===============Description============== ========User=======>> 50<end> 50<04 <13 <40 <19~ 50<end> 502 50File name 50Description 50User name The "50" means this is block number 50 in DB_BLKS.TXT (and it comes only after block 49 and before block 51). 50Fuzzy Bear's data base of warez. 50 50<end> Is our description text. It can be any number of lines, but must be at least two lines, and the last line must contain only "<end>". It may contain LINES.TXT codes. A CR/LF is assumed after each line. When this database is called, it will clear the screen, print the BBS heading, print "Fuzzy Bear's data base of warez." in dark green letters, skip a line, then ask the "List, Add, Modify, Delete, Insert, or [Enter] to quit" question. 50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT This is the file name in which we store our database. You can specify any pathname you want. 50S12S40U This is the database's definition specs. The following are currently allowed: A for an attribute field. Inputs and displays attributes using "1234567890ABCDEF". D for a date field (dd-mmm-yy). Odd is that you will see dd-mmm-yy, but when entering the data you must use the old mm/dd/yy format. F for file areas. Input is for a 3 digit number, but output contains the number and the title of the area. I for an integer number (-32767 to 32767). L for a long number (-2,100,000,000 to 2,100,000,000). M for message areas. Input is for a 3 digit number, but output contains the number and the title of the area. N for a net address (xxxxx:xxxxx/xxxxx). S## for a string of length ##. ## must be two digits. Example: for a string of length 4, use S04. S64 is special: it is considered to be a pathname, and -153- will be created if it does not exist and the entry you make ends in a "\". T for a time field (HH:MM:SS). U for a users name. The auto-name-detect is in effect so only active BBS users names are allowed. Use S30 for non-auto-name-detect name fields. W for the seven days of the week (MTWRFSN). "R" for thursday and "N" for sunday. anything else will cause trouble. Our example describes a database of 3 fields: a size 12 string field, a size 40 string field, and a user name field. For a total record length of 82 characters (user names are limited to 30 characters). For those who need to know: A, D, F, I, M, T, and W are stored in 2 byte integer form, L and P are 4 byte long form, U is a 30 byte string, N is a 6 byte string, and S## is a string of length ##. 50record number : This is the "modify which entry" question fragment. For adding, deleting, inserting, etc. it asks "Modify which ..." and appends the above. 50warez This describes what we are working with. It is used when listing. As in "List of all warez." 50 -------- Fuzzy'z Warez Data Baze --------> 50 Rec ==File Name== ===============Description============== ========User=======>> 50<end> Is our header text. It can be any number of lines, but must be at least two lines, and the last line must contain only "<end>". It may contain LINES.TXT codes. No CR/LF's are added unless you put them in with ">". 50<04 <13 <40 <19~ 50<end> This is our output display definition line. It contains two defining elements: "<##" which is the length to use, and everything in between. For each definition in our definition specs, there should be a corresponding "<##". You cannot not-do a field, but can not-show a field by using "<00". The first one is for the record number. Two numeric digits are required (for example, not "<9", but rather "<09"). -154- The example tells the software to display a line of the database as so: Turn bright green on, display the record number in a area 4 characters wide, display a blank space, turn bright blue on, display the filename in a area 13 characters wide, display a space, display the description in an areas 40 characters wide, display a space, display the user's name in an area 19 characters wide. We could have used two spaces before <13 and used <12 instead, or no spaces before and <14 instead--since the field is only 12 characters in length, the first two will always be spaces. The <19 truncates our 30 length file name. Output lines cannot exceed 79 characters (the software chops off anything longer). A "~" will be replaced by a CR/LF. All lines before the <end> are merged together before handling is done--so instead of thinking of it as a bunch of separate lines, think of it as one line broken up. When displaying, the following formats are used: Time: fixed "00:00 xm" format. User name, String: left justified. Integer, Long numbers: right justified. Days of week: MTWRFSN with "off" days getting a space. Attributes: 1234567890ABCDEF with OFF bits getting a space. File/Message areas: "### title" with title left justified, use <## to limit what you want to see. Node address: "xxxxx:xxxxx/xxxxx" format. 502 When accessing this database, we may use "!" to select by field. This line tells the software to use the 2nd field (Description). This line can only specify a S## (string) field. If you have no string fields, you should put a 0 here. 50File name 50Description 50User name These are the field names used when entering/modifying a record. Simple names, one for each definition spec. You may include ANSI codes to colorize them. When entering a day of the week, or attributes, they can be in any order, MRF need not be entered as "M R F ", for example. -155- Because it is easiest to start a new database by merely first copying the definition of another database, the most likely problem that occurs is that one forgets to change the blocks' numbers to give it a unique block number. The limits: 32,767 records with maximum record/field size of 4096 bytes. Maximum of 24 fields (any more screws up the screen editing). I know the above sounds rather technical, but there are 50+ that you use already as part of the sysop menus that you can use as examples. Calling Via Calling up a database involves using a "DBEd" or "DBVw" menu Menus commands. Any user with access will be able to do all the functions (List, Add, Modify, Delete, Insert, etc.) with "DBEd". Users are only able to List the contents of a database using the "DBVw" menu command. See also: DBEd, DBVw Modifying When modifying the data, just hit [Enter] at the start of the line to not change what is already there. The software will jump through hoops to try to keep groups, Messages, Files, etc. in proper order as you Delete/Add/etc. new areas. However, commands that make a specific reference to an area are not adjusted, and you may need to do it by hand later. Example: if using a "DOOR _15" command on a menu, and then you delete door entry number 10--so what used to be door entry 15 got shifted to number 14. More When listing, lines that are just "S##" commands that are themselves empty, are not displayed. For example, a Title line, which is an S50, is not displayed if it is blank. The purpose of this is reduce screen clutter of unnecessary information. EXAMPLE ┌───────────────────────────────────────────────────────────┐ │ Let us create a "news items" database. In which users │ │ can add/delete/modify/list entries of news items they │ │ think other users would be interested in. │ │ │ │ Step 1 │ │ Find a location for our DataBaser definition block in │ │ DB_BLKS.TXT. Usually just use the next one following │ │ the last block in the file, for example, we will use │ │ 43. │ -156- │ │ │ Step 2 │ │ Create some informational text for whenever this │ │ database is used. │ │ │ │ 43Important news items you wish all to see. │ │ 43 │ │ 43<end> │ │ │ │ This displays "Important news..." in dark green │ │ coloring followed by a single blank line. │ │ │ │ Step 3 │ │ Assign a file name to store our data. │ │ │ │ 43C:\BBS\GLOBAL\SYSTEM\NEWS.DAT │ │ │ │ Step 4 │ │ Define the data structure to use. We want a more "free │ │ flowing" structure than normal. │ │ │ │ 43S72S72S72S72 │ │ │ │ Which is 4 lines of length 72 (4 string fields of │ │ length 72). We could add more (or less) of these, we │ │ could change their size, etc. But this provides a good │ │ balance between drive space and entry size (each entry │ │ will use 4 * 72 bytes of drive space). Also, it is a │ │ good size to fool the user into thinking they are not │ │ entering into a database--as it will look like a text │ │ file (when we are done). │ │ │ │ Step 5 │ │ Now we enter the text for the question when a user │ │ selects to modify a record. │ │ │ │ 43news item (1..n top down)? │ │ │ │ Step 6 │ │ Identifying the record. "What it is" we are adding, │ │ etc. This is meant to be a singular noun. │ │ │ │ 43news item │ │ │ │ Step 7 │ │ Create a heading. │ │ │ │ 4326 News items of │ │ 43 interest.>> │ │ 43<end> │ │ │ │ We output "News items of interest.<ret><ret>" in bright │ │ green for our heading. │ -157- │ │ │ Step 8 │ │ Design the record display line. Here is where we take │ │ advantage of some of the DataBaser system's qualities. │ │ │ │ 43<00 <72~ <72~ <72~ <72~ │ │ 43<end> │ │ │ │ We use " <72~" to print out each of the record lines │ │ with 4 spaces in front and a CR/LF afterwards. If the │ │ line/field is blank, then DataBaser will not output it, │ │ because it does not output lines with only one field, │ │ and with that field blank. The "<00" says to not │ │ output the record number (actually, it says "output the │ │ record number into a field of size 0). The last "~" │ │ will result in an extra CR/LF between the outputted │ │ records. │ │ │ │ So, now when we list, it will list all entries, │ │ separated by a blank line. It will only list as many │ │ lines per entry as contain data. Example: an entry │ │ with 2 lines of text shows only 2 lines, etc. Not a │ │ steady 4 lines per output record, even though the │ │ record can work with up 4 lines--by stopping output of │ │ "blank" lines, the actual number of displayed lines │ │ will vary with the number of fields witch actually │ │ contain data. │ │ │ │ 43}7<02 <72~ <72~ <72~ <72~ │ │ 43<end> │ │ │ │ Could be used to display the item number as well. │ │ Above the items appear in the default dark white color, │ │ here we turn on dark blue for the number, and dark │ │ white back on for the text. │ │ │ │ Remember, this entry does not define how each line of a │ │ record is to be displayed, but rather how the whole │ │ record is to be displayed. │ │ │ │ 43<00|o| <72|o|~|o| <72|o|~|o| <72|o|~|o| <72|o| │ │ 43 <*-+-*> │ │ 43 |o| │ │ 43<end> │ │ │ │ This is another example. This displays each item in a │ │ "paper feeder" like format. With a short design as a │ │ separator. Remember that the lines are all linked │ │ together to form a single string. │ │ │ │ Step 9 │ │ We have no fields which could be used to select records │ │ with the windowed selector, so we just use: │ -158- │ │ │ 430 │ │ │ │ Step 10 │ │ Because we have defined four fields (S72 * 4) we must │ │ now give each a name (for when we add/modify the │ │ entry). │ │ │ │ 43Item │ │ 43Item │ │ 43Item │ │ 43Item │ │ │ │ When adding/modifying an entry, we will be adding to 4 │ │ fields with the same name. But because the whole │ │ record is considered a single news item, this is quite │ │ appropriate. │ │ │ │ Finally │ │ We have completed a new database. Now we just give it │ │ an entry on a menu's ANSI, and a matching entry in │ │ McEditor with the command "DBEd _B43". Review the menu │ │ system for help with this procedure. │ │ │ │ NOTE │ │ While this database was designed to let users add │ │ entries, you can utilize it as your primary news file │ │ as well. Either replace the "Dnws" with a "DBVw" or │ │ add a "DBVw" command before or after "Dnws". Then when │ │ users log on, they will get a listing of your news │ │ DataBaser contents. │ │ │ │ One drawback with this database--any user can modify │ │ any other user's news item. Well, it might actually be │ │ useful here, but it would be disastrous if this were, │ │ say, a Buy/Sell/Swap database. │ └───────────────────────────────────────────────────────────┘ -159- LIFE & DEATH There are many aspects to this capability, as it has many DELETE requirements and conditions that must be met to both implement it and for a user to use it. This section only covers L&D Delete, the Life & Death system is better explained in the Toggles and Menu Commands which implement it. To implement it: Set the toggle to allow it to ON. In "Change Settings", set a minimum amount of drive space before this becomes active, and set a minimum user SL value who may use it. In your menus, have an entry for "Asst" (usually in your login loop). Use an "ifSL" entry to give it the same SL value as we do in "Change Settings". You may also need to specify a file contents listing form type directive to display the L&D value for each file. To remove it: Set the toggle to allow it to OFF. Remove the "Asst" menu entry. Every thing is individual. "Asst" will display the AI help request to anybody, which is why we set the SL field in the menu command itself. When using the L&D system, any user may attempt to delete it--which is why there is a Change Settings SL value. That user could do it at any time, which is why there is a "only if less than this amount of drive space" Change Settings field. It is complex because it needs to be. This capability allows users to delete files from your download directories. So you must be able to define who can delete, and when they can do it. Users will not be able to use L&D Delete to delete files in "CD" File Areas (those with Attribute 9 ON). -160- MULTI-NODE This software has complete multi-node capabilities. OPERATIONS To use it under multiple nodes, you will need a multi-tasker like DesqView, Windows, OS/2, etc. SHARE.EXE will need to be installed for multi-node operations under MS-DOS and DesqView (not sure about Windows, or OS/2). See the HELP directory for sample DV and Windows .PIF files. One thing that should really be useful is a "sysop node"--you set up a node that nobody can contact via the phone, and just switch to that multi-task window when you want to logon. This allows you to avoid waiting to access your own BBS. Steps to making a Node 2: 1) copy the whole NODE001\ tree into a NODE002\. If the second node is just for you, you don't have to copy over any Styles\Languages you don't use. The main thing we want is that NODE002\TEMP\ directory. 2) copy BBS001.BAT to BBS002.BAT. Then edit it so it contains /NODE=2 rather than /NODE=1. 3) now restart node 1 as normal (BBS001.BAT). Then go into "Change Settings", and change the Node number from 1 to 2. This will create a SETTINGS.002 file. 4) Log out of node 1 as normal. Then with your multi- tasker switch to/create a task for node 2. Then run BBS002.BAT from that task. Thus, you now have two nodes. BBS001 starts node 1, BBS002 starts node 2. If your node 2 is a sysop-only node, you'll want to change its comm port right away to 0 (local-only operations). Although if you have two modems installed, you can also just use that comm port (maybe for calling out, etc.). If you use the sample .PIF's you will probably be OK. But feel free to play around. It is important that you have a good idea of how to use your multi-tasker before trying this. More than one node is more work. You need to implement multi-node modes for many door games, for example. The main thing to remember about multi-node operations is that when you change things for one node, to remember to do it for the other nodes as well. Such things include menu commands, text, and ANSI files. Multi-line BBS's have a few pitfalls that it is the responsibility of the sysop to avoid: -161- One pitfall is lack of drive space--always make sure your basic empty space is enough for all the nodes (about 1 meg per node should be available free on disk at all times). With events: that you specify a node for each. With net mail: that you don't have multiple nodes sending/receiving for the same zone at the same time. Important: The Settings and Toggles are node-independent, you can change these for each node. Example: you could toggle on "must validate uploads" for node 1, and toggle it off for node 2. Pathnames, however, are not (which is why we have the "???" and "***" specifiers). Never shell to DOS and modify the various BBS-use block text files (TXT_BLKS/DB_BLKS/etc.). You must do a full exit, then edit them, and then restart the BBS (all nodes). The reason is simple: the software maintains an index of where each of these blocks start in the text file--adding or removing characters screws up this index, and could really mess things up. When you restart the BBS, restart it in an orderly fashion: wait till node 1 is up and going (at or past WFC) before going on to node 2, etc. There are some things that when you change you should restart all nodes so they learn about the changes: When you change LINES.TXT, TXT_BLKS.TXT, SYS_BLKS.TXT, PRG_BLKS.TXT, DB_BLKS.TXT, SHORT.TXT. When you add/delete Security Levels, Message Areas, File Areas. If you do something minor, like change the number of access minutes for an SL, then there is no reason to go through the hassle of restarting the BBS--the other nodes will get that minor change eventually. When you change pathnames in Alter Pathnames. You may want to make the Trap All and Trap Chat files node dependent. It depends on how much you use trapping. See also: FILE AREAS, LANGUAGES/STYLES -162- INTERNAL NETS These are networks between two or more computers. Such as linking up all the computers in your home. For all of the above, you should not specify a "0" for comm port. They must point to valid comm ports to work properly. Null Link This involves connecting computers via a null modem and using JDR_BBS as a medium on one or more of your computers. You must specify in your fossil driver line each port. For instance, I have an old HST connected to COM1 and a null modem connected to COM2, and use the following CONFIG.SYS line: driver = x00.sys b,0,19200 b,1,19200 r=4096 t=2048 e 2 Which locks the baud rate of the old HST (b,0,19200) on COM1 and the null port (b,1,19200) on COM2. There are two ways to connect up two computers via a null modem using JDR_BBS. The first method is for when both computers are running JDR_BBS. This involves going to the waiting-for-caller screen of both computers, and selection <alt>p and changing two whatever comm port the null modems are connected to. This is a hard link, from which you can use <alt>s, <pgup>, or <pgdn> only. The second method involves JDR_BBS being on one computer run as a straight BBS, and JDR_BBS on the other computer in <alt>d. For both computers, you will need to first use "Change Settings" to set the comm port to your null modem-- you will need to repeat this step when you are done. This allows you to use all the <alt>d commands. You can mix and match the above, <alt>p, <alt>d, Settings, it does not really matter. What matters is that you get both computers pointing to your null modem. It might be more convenient to set up multi-tasked "sysop nodes" on each computer already pre-configured as a null modem connection. Giving it no timer ticks until you need it. LANs LANs are computers networked together using something like a LAN card. LANs hooked up as a way of storing your on-line files, or with each computer handling a node is no problem at all. -163- But if you want the networked computer to act like a dumb terminal to the BBS, then you need to configure the LAN card like a comm port. That is, the software will send and receive data only to comm ports.. So if you can configure your LAN card to work via a fossil like X00, it will have no trouble acting like a sysop-only type node. There is a Miscellaneous Toggle related to this. When this toggle is ON, the BBS will not try to reset the modem for that node, and will simply wait at the login screen until a user logs in. Null LAN For lack of a better term. Interlink was real easy to set up. First, on your main system, (the one with the BBS on it) all you have to do is add "Device=c:\dos\interlink" to your config.sys. On the second machine, just type "intersvr" at the dos prompt. Thats all there is to it. When the first machine (the main one) is booted up again, it searches the second one and adds all the drives on that machine to the main one. That is, you can now access the second machine's drives from the first one. In the BBS, all you do is change the individual file areas to point to a drive on the other system to use it as a file server. If I got you confused here, I'm sorry. It's really quite easy. The only added expense is buying the interlink cable. It cost me 8.99 at radio shack. It was made just for interlink. The only drawbacks are that the second machine is now only a file server. You can't use the system cause when you take it out of interserver mode, it breaks the connection. Also, getting a printer to work might be a little tricky. I had to tell my printer software to use "lpt2_dos" as a port to get it to work. Other than that it really is a lifesaver of a program. It frees my main system's hard drive up to do more with. I use the other system strictly as a second hard drive for the board. --Roland Parent It frees a possible Stacker drive (which normally would be very inefficient with File Areas), and allows one to get around the 2 drive IDE limit. The cable Roland mentions I think is just a null modem and connecting cable. -164- FILE With all the I/O being done, it is inevitable that you are CORRUPTION going to get some sort of file corruption. Executing a: CHKDSK /F will fix these problems. However, CHKDSK may fix it by increasing a files size (particularly for allocation errors). For text files this is not a problem. For the USERS.HDR, FILELIST.HDR, and MESSAGES.HDR, you should run the appropriate integrity testing command. For other .DAT files, you can use their DataBaser menu commands to edit them to find any visible problems. If you have Trap All ON, and shell to DOS and delete the SESSION.LOG file, you most likely will get a fatal "sector not found on drive d:" and have to reboot the system. This occurs because I do not close my files when shelling to DOS. The reason I do not close them is because <alt>s could be hit anywhere, and I have no way of knowing which files are open. DOS does not like you deleting its opened files. If any of the .IDX index files become corrupt, just delete them and restart the BBS, they will then be recreated (you should restart all nodes). You can tell the users index, for example, is corrupt if you are not allowed to enter what you know to be a valid user's name, or if the data returned about an account is wrong, or that of another user. You can tell the files index is corrupt, for example, if after entering two characters of a filename to download the system crashes. Generally, if something is acting bad with messages or files, its usually that a .IDX file got messed up. File corruption doesn't occur a lot. But computers today are increasingly hostile places for files. Virus's, for example, have ballooned into a real threat. You should make some effort to back up your BBS regularly. By far, the reasons most BBS's go down is a) because the sysop got tired of it, and b) because the HD crashed. -165- SPECIAL THANKS To the users of Immortality--who have been putting up with oft-times flaky software and a non-attentive sysop for three years now as I have developed this software. Ray Elquist. Who, despite being long distance, was largely responsible for beta testing .09. His many found bugs and ideas have caused the long delay between the .08 and .09 releases, but the program is much better because of his help. Bob Ratliff. Who seems to be spending so much time testing BBS programs that I wonder why he registered. His dissatisfaction has made the .10 version easier to use. -166- NEXT There are docs, doc files, and help files hiding everywhere. If you really want to read more docs, then seek those out. But no hurry, play with the software some more--it gets better the more you use it.